The first big decision when building a web or mobile app for your business is which tech stack to use.
It can be complicated, especially when you’re in unfamiliar territory.
In this article, we’ll discuss exactly why your choice matters so much. We’ll explain several of the major pitfalls that many business owners stumble into. We’ll also get you started with a framework for asking questions and examining your core drivers. Then we’ll run through a real-world example to show you how it all works.
Rather than simply comparing two frameworks, or listing our favorites, our guide will walk you through making a decision based on your needs, limitations, and goals.
With this information, you’ll have the confidence to choose a stack that’s as close to perfect as possible.
Why Picking the Right Tech Stack is So Important
Don’t be tempted to race through the tech stack selection process in order to make a start on development. This step is crucial, and should be carefully considered before making a decision.
There are multiple reasons why this choice deserves your careful attention.
Building technology is no easy feat. It takes time and often requires a considerable investment.
If you end up having to start over from scratch, it will be not only incredibly frustrating and time consuming, but extremely costly and possibly even catastrophic for your project.
So take the extra time to make the right decision up front and save yourself and your budget from having to rebuild a year from now on another stack.
It’s not only the project that will determine how long your technology takes to come together. It will also involve the people working on it and the stack itself.
All these factors will govern how quickly you can move forward and when you will be able to release new features to your customers.
Be sure to take into account how slow or fast your tech stack is to work with and build these estimates into your launch timeline.
Most modern companies have access to very similar sets of technology and skilled workers. However, anyone can see that the quality of final products varies greatly from one service to another.
Often, this noticeable difference in quality comes down to that initial decision on which tech stack to use. Making the right decision there can lead to a significantly better product in the long term, even though the stack is not something most consumers will ever consciously think about.
When you make the best decision about which tech stack to use, you may be more likely to bring the project to completion.
In some cases, projects will grind to a halt because of poor technology. In others, the great majority of the effort and money sunk into a project will be wasted, with no results, for the same reason.
The right stack will help to ensure money and effort are not wasted and that progress is not impeded by the platform.
Common Pitfalls to be Aware of When Choosing a Stack
You are not the first to make a decision about which tech stack to use, which means that you can take advantage of the fact that many have made mistakes before you.
Here are three major pitfalls to be aware of when making your decision.
Blindly taking advice
When you aren’t familiar with the subject, it’s only natural to turn to friends, family, and outside vendors for advice. It’s also extremely common to follow that advice when these sources of information are assured in their opinions.
However, you’re the one ultimately responsible for making the right choices and for paying the bills.
Others tend to inject their expertise without a full understanding of your unique situation and project requirements. They have no responsibility to you, and often won’t ask all the in-depth questions that need to be answered in order to find the best tech stack solution. So while they might sound like they know what they are talking about, it can be more about their ego rather than what is best for you.
And once they pass out their advice, they might never think about it again. You, on the other hand, will be the one dealing with the consequences of their best intentions.
Additionally, outside vendors might know their products well, but it’s best to take their advice with a grain of salt, as they are still selling a service and therefore can have ulterior motives.
Listening to advice can be helpful, but putting the hard decision-making process into the hands of marginally invested outsiders can easily lead to mistakes and difficulties down the road.
Having a little experience
Perhaps you have dabbled in tech stack in the past and therefore have a little experience with one of the options.
Sometimes, this can be worse than no experience at all.
With no experience or prior knowledge, you may be more receptive to considering all options before making a decision. With existing experience, you may be more inclined to go with what you know, rather than what is the best fit.
Instead, use your experience to fully research options you are less familiar with to make an informed decision.
Letting your budget make the decision
I get that everyone wants to save money but seeing funds as the only driver tends to give you tunnel vision.
If your budget makes decision for you, it can mean bringing in the cheapest talent, including the most inexperienced advice and skills on the market. In the long run, this can cost far more than you saved.
By making proportionally larger investments in the beginning, the added quality you’ll see over time can help you save money overall.
Three Key Drivers to Consider
At the heart of the decision lie a variety of factors you’ll need to carefully consider one by one.
As you work your way through each element, remember that there is no perfect choice, but there is a near-perfect choice. You can and will find it by identifying your top business objectives, as well as your strengths and weaknesses in relation to the range of technology options.
Much like a simple list of pros and cons, your method for making a decision should help you visualize the best option for your situation, without letting top-of-mind concerns drive the choice and eclipse the more nuanced factors.
The elements to consider fall into three groups: business drivers, situational drivers, and technical drivers.
1. Business drivers
Business drivers are a good place to start, as both situational and tech drivers essentially all tie back to these factors, and can either improve or decrease your chances of achieving your budget goals, timelines, and outcomes.
The first of your business drivers is your budget. You must take into account how your finances are structured, such as whether you have a lump sum in the bank ready to go (and therefore few options to access more funds should an emergency arise), or you have a steady revenue stream from other products or services. Or perhaps, you have the option to source additional funding should you meet your targets.
You must also consider whether burning through your funds prior to the completion of your project would spell disaster in the form of bankruptcy.
The second business driver is your timeline. Are you limited to just a month, or can you stretch the project out over a quarter? And what are the consequences of missing a deadline?
Be sure to lay out how long each stage will take, allowing a little wiggle room for mistakes and setbacks, to get a realistic timeframe of the entire project.
Finally, the third key business driver is your ideal outcome. What are you trying to achieve in the short term? Are you looking for funding by proving a concept? Are you working on a second version with a precise roadmap thanks to learning from version one? Is there a particular deadline you must meet in order to be successful?
2. Situational drivers
Situational drivers might not seem like the most obvious factors in your decision, but they can help you to make a fully informed choice.
A major driver in this area is your in-house institutional experience. Ask yourself what type of in-house talent you already have and think specifically about the skills and experience that are likely to stay with the company until project completion. If you can assume that talent will remain throughout the project – possibly due to their involvement in the project development either personally or as a leader – this can represent a lot of value.
On the other hand, if your in-house talent drives your decision but comes with no assurance that the talent will remain with the company, their expertise may become more of a liability than a help.
Another situational element to consider is whether you are inventing new tech, or are using existing tech to bring a new idea to fruition. In cases where the tech already exists, it can make life easier to follow the path of least resistance and lean on what has already been created so you don’t have to reinvent the wheel. Then you can put your time, effort, and budget into building the best product you possibly can.
Take a look at similar products or services on the market and delve into what they used for inspiration.
You must also think about how much time you realistically have to invest in this project as a manager. Will it be your sole focus, where you spend each day dealing with questions and roadblocks? Or will you have other areas to work on outside of the new project, limiting the time you have available to spend on development and issue management?
The less time you have for oversight of the project, the more likely it is that you will need a tried and trusted platform that offers more developers and community support that can carry the project ahead when you are not available.
It’s also a good idea to factor in just how certain you are about your big idea. Is your project definitely something that people need and will use, or are you still trying to find out if the market is as excited about the idea as you are?
If you already have certainty, you should already have a clear idea of your design, UI, and backend functionality. If you are unsure, you may need to be more flexible during the project and make adjustments as needed.
The final situational driver is that of your staffing situation. If you don’t already have the talent on board to complete the project, you’ll need to take into account how easy or difficult it is to find qualified developers in your area, or even remote workers if you are comfortable with managing virtual teams.
For managers working in smaller regions, it can be much tougher to find qualified, available talent in the less popular tech stack languages. This can mean you may have to make a compromise and choose a more popular language in order to complete the project with local workers.
3. Technical drivers
When you look specifically at the technology at hand, you’ll find a variety of elements that also need to be considered as part of your decision.
To start, take a look at the tech stack you’re considering. It was likely developed as a solution to a problem, or to make a project easier. Are you, and your project, the target market for this particular tech – would it solve a similar issue for you? If not, you may be trying to force your project onto a stack that isn’t particularly well suited to your needs.
When it comes to tech, community is key. A supportive, close-knit group can speed up your development immensely, as you will always have help on hand for dealing with difficult questions and issues. Without a supportive community, those issues can become immovable roadblocks that lead you to abandon your approach, wasting time, money, and mental zest for the job.
Many modern technical projects aim to meet audience needs by offering support across several platforms – including iOS, Android, and even desktops. If this cross-platform requirement applies to you, you will either need to run several projects at once to meet your goals, or opt for a tech stack that compiles to multiple platforms with one codebase. The latter is certainly the more affordable option, and can also make the process faster and less stressful thanks to fewer components.
When you’re researching stack options, note when the technology was created, and when it was last updated. This will have an influence on whether the community of developers working with it is growing, steady, or declining, and therefore whether it will be a solid choice for developer support in the long term.
Some tech stacks are easier to start with than others. Option A might take just a few clicks to get underway, while Option B might take hours and considerable skill. In some cases, the additional time and effort pays off with extra features or a more suitable tech overall, but if both options result in the same features, the one that’s faster to begin can save you time and funds.
Yet another factor to consider is the ease of deployment. Will it be a challenge or a breeze to get running into production? A hosting platform that can do the heavy lifting for you can be a huge help, and if that system will autoscale with user base and data growth, even better.
A quick and easy deployment can help you stay on budget, and won’t drain your resources by needing to deal with a complex system for rolling out the project on top of your software development.
Speaking of scaling, you’ll need to think specifically of how you will scale up over time. Asking a developer to “make sure it scales” is too vague, and even if they say that it will scale now, it’s unlikely to have the right capabilities when you actually need it to.
Instead, think about how you might grow in time. It could be with increased anonymous traffic, or with more registered and logged-in users. It could be with countless queries, or practically anything else. Be sure to factor in this future potential in these early stages.
Finally, the last major technical driver is that of the speed of development. Do you need your tech stack to offer a rapid development process? Will speed force you to compromise on flexibility or features?
Be sure to include development speed, and all other technical drivers, into your big picture to make the best decision you possibly can – your near-perfect choice.
A Working Example of a Tech Stack Decision Process
So far, our advice has been purely hypothetical. So let’s go through a simple example so you can see how these drivers and design-making considerations work in a real-world scenario.
Keep in mind that we are not here to make the decision for you, or to create a list of pros and cons to compare two languages. Instead, we aim to highlight the key questions you should be asking yourself that will drive your decision so that as you read, research, and speak to professionals, you have your own existing system to ask the right questions and cut through the noise.
That said, let’s work through an example.
Your elevator pitch
Let’s assume that you are an EdTech startup, with a $50,000 budget unless something big comes along.
You’re aiming to build a mobile app that must support Android and iOS, and you’d prefer it if it looks and feels like a native app.
You are not technical yourself but will need to manage your technical workers, and you have no experience in building tech yourself.
Analyze the situation
Start by learning the very basics of tech building – even if it’s just a quick introduction to the jargon, acronyms, program names, and key features. As you are just starting, even a small amount of knowledge can go a long way and help you feel more confident moving ahead.
You won’t understand everything – and don’t need to – but it will help you to become acquainted with the subject matter in a way that will let you spot common themes and current market opinions.
For mobile development, run a Google search on The best mobile platforms in 2019. You can ignore the paid advertisements and read roughly half a dozen articles. You’ll quickly start to see common products, such as Ionic, Reactive Native, Xamarin, PhoneGap, Flutter, Corona SDK, and JQuery Mobile.
This will further familiarize you with popular platforms and what makes them so well-ranked amongst developers.
Next, it’s time for numbers. Take a look at the statistics each option boasts – how many people use it? How many developers are fluent in it? What do developers and clients love about it?
Stack Overflow is highly useful for this step, as it publishes an annual report that outlines key information in their Developer Survey, which will give you insights into the minds of thousands of developers working in the field. It’s essential to cross reference this survey with outside information, but it is a fantastic place to start for perspective.
This survey tends to highlight a handful of options enjoying the limelight. React Native sees a lot of use for mobile development with roughly 10% of developers opting for this tech, and even though Flutter is the most loved by survey respondents, only 3% actually use it. From figures like this, you can see that you’ll have an easier time hiring React Native developers, although Flutter may be one to watch as it could rise in popularity in coming years.
Next, it’s time to turn your attention to the age of each platform. React Native is a more mature stack, initially releasing in 2015, whereas Flutter is just a couple of years old. However, both are updated regularly.
Simple information such as launch time and updates are easy to track down, and with the other elements you have already considered, you should be feeling much more comfortable talking about and researching these platforms.
Assuming you are now looking closely at Reactive Native and Flutter, the next step is to read as much as you can about them. Again, aim for half a dozen articles that cover their key features, pros and cons, all the while remembering your specific drivers.
It’s a common misconception that you need a tech degree for this phase, when really you are more than capable of researching these platforms and comparing them with your needs. At this stage, you can also introduce the opinions of friends, potential vendors, and business contacts, which can verify or dispute the conceptions you already have.
The difficult part of this phase is that in reading countless blogs and listening to many opinions can lead you to feel overwhelmed. If this happens, go back to your drivers and remember what’s important to you and your project.
In this case, the strong choice is React Native. It offers more developers, has been around longer, works on a budget, and offers support for Android and iOS with a Native feel. By satisfying these key drivers, you are taking on less risk in meeting your true business outcomes.
For the backend, simple is best. You can even avoid servers altogether by using a service such as AWS Lambda, which lets you build a backend that scales with you, doesn’t require ongoing server maintenance, and only costs you when you’re using it.
A similar rule-of-thumb applies for the database as well. Opt for a managed database, as even with a higher monthly fee, it will usually cost less overall than paying for a developer.
Tweaking the scenario
Even though React Native can seem like an obvious choice in this example, it wouldn’t take much for Flutter to offer a better set of features.
For example, perhaps the budget is still a concern but you can add an additional $5,000 per month for the project on an ongoing basis. Also, let’s say the priority is actually to support not just Android and iOS, but also desktop and web browsing, and to all feel exactly the same (rather than native).
A fixed budget would make it wise to avoid a newer language like Flutter, but with this new monthly cash injection, it becomes a much more attractive option. Additionally, Flutter specializes in building just once, and supporting across Android, iOS, desktop and the web with a single codebase. It offers modern UI elements in all platforms, and while it doesn’t look native, the consistency may be an appealing new option.
Also, with the ongoing additional budget, you can invest more funding into finding the right developers for the job, and the bonus of Flutter using a single codebase can save you from developing across platforms in time.
Even so, Flutter may still be a viable option for a fixed budget, especially if you’re looking to build across multiple platforms in a short timeframe. You may need to compromise on features to allow room in the budget to find the right talent (for the right price), but this single code system will allow you to move faster.
Once your product is more mature with a stable app feature set and regular paying customers across platforms, you can start looking further ahead.
With income from regular customers, you can now start paying for full-time developers to bring your app to perfection (or at least, near perfection) on Android and iOS.
You may even be in a position to develop truly native apps in both Swift (iOS) and Java (Android). This would give you the space to create truly fluid and performant apps that customers would expect from a mature product. This move would take more time and investment however, so should also be considered carefully.
Where to Go From Here
There’s a lot to think about when it comes to choosing the right tech stack for your business, and even when you feel you have found the ‘near-perfect’ solution, there are countless ‘what if’ scenarios that can change things.
Feel free to contact me directly if you have other scenarios you’d like to hear my thoughts on.
In the meantime, remember to think about your drivers, learn the basics of tech stacks, and get familiar with researching your options. By crossmatching all your collected information with the wealth of advice available to you, you’ll be in a good place to find your ‘near-perfect’ stack and create the perfect outcome.