How do I Make the Right Tech Stack Choices?
Choose the right tool for the job
This phrase is well-known for a reason. No matter what kind of problem you’re solving, the wrong tool can lead to problems. And if you’re starting a business, poor choices in tooling might have a massive impact on your growth and scalability in the future.
They might have a massive impact! Might.
Much more likely is spending too much time deciding on the perfect tech stack, setting up infrastructure, and customizing the user experience, only to find out that:
- the only growth and scalability issues you’re facing are of the opposite kind. Less like a hockey stick, more like a flat stick lying flat on the floor of your friend’s flat. Or,
- if you do find growth, that it ends up requiring big changes in your tooling compared to what you imagined you’d end up building.
In this post, we’re going to outline a minimalist framework for deciding what tech stack you should build on. Minimalism is important here because our goal is to not waste time, while still accomplishing what we think we’ll need to test our assumptions.
Here’s a quick overview of the guidelines:
- Ignore the trends
- Build as little as possible for as long as possible
- Ballpark initial requirements
- Use what you know
I should note: A fundamental assumption here is that we can’t know exactly what will happen in the future. If this doesn’t apply to you, feel free to ignore all of this advice. Also email me some stock picks, yeah?
Ignore the trends
In the world of software development, technology changes quickly. If you operate in the JavaScript ecosystem, a tool that came out a year ago may already feel out-of-date! And there is nothing wrong with wanting to experiment with new goodies and see what is possible.
But it’s best not to mix new technologies and new businesses.
If you’re looking to get your resumé sharp and bone up on the latest libraries and frameworks, feel free to experiment with new tech. If you're looking to build a successful company – and you’ve decided that you MUST build (see next section) – ignore the latest trends and follow these rules.
Build as little as possible for as long as possible
Builders love to build. But building costs time and money. Perhaps even more importantly, maintenance cost is a multiplier that is rarely considered fully.
As much as possible, avoid building new tools by:
- Re-using existing code
- Buying off-the-shelf solutions
- Finding solid open source packages
The trickiness here arises from understanding how much customization (if any) is needed and how much is easily achieved with any pre-existing options you find. In order for you to make those decisions, you’ll need to understand your initial requirements — more on that later.
Eventually, if your product or service gains traction, you may need to scale your solution. Here is the key: by then you will have much more information about what tools to invest in. You will be able to make more educated determinations about which pieces need to be scaled and in what way.
Even as you grow, you should continue to minimize your time and money investment in technology. Since you have the least room for error at the beginning, it is most important then. But always remember to build what you need, but only what you need.
NB: Having trouble remembering to build as little as possible for as long as possible? Just use our handy mnemonic: BALAPFALAP!
Ballpark initial requirements
One thing you can be pretty sure of: you won’t start out knowing exactly what tooling you’ll need for your “final” product. You will pivot while trying to meet your customers needs.
Instead of trying to architect a full solution, decide what your first step looks like and determine the smallest build to get there.
How do you decide what your first step looks like? Ask yourself what hypotheses you are testing by going to market.
- Do you need to confirm if people want what you are proposing to build?
- Do you need to know if people will pay $X/month to solve the painpoint you’ve uncovered?
- Do you need to know if your solution is technically feasible because you’ve already ensured that people will pay you enough to cover your expenses?
In two of these three situations, you can find an answer without actually building significant tooling, just by buying off the shelf or, for example, re-using an existing blog solution.
Even in situation #3 you may be able to test your potential solution with a barebones prototype build, or by hacking together existing products (e.g., IFTTT, Google Sheets).
Understanding what you are trying to learn informs what you need to build. Understanding in detail what you actually need to build vs what sounds like the most fun to build will minimize your tech stack. That means reductions in opportunity cost spending and maintenance commitments down the road.
FYI, it’s perfectly okay to try to not paint yourself into a corner by avoiding building critical components using tools that lead to lock-in. Just remember that over-engineering is 976.3 times more common than finding yourself completely unable to scale.
Use what you know
Once you’ve established your estimated initial requirements, determine if any can’t be met with tools you already know or can buy off the shelf.
To make this clear: if you are a capable engineer you can probably imagine a more powerful solution that you could build yourself. Don’t build that unless what you have or what you can buy can’t do a good enough job to get you started.
If at all possible, sticking to the tooling you already understand will save you vast amounts of time and pain down the road.
Avoid the unforced error!
Summary
These guidelines will help you pick your tech stack quickly so you avoid wasting time investigating and exploring new technologies that might be fun but won’t get you any closer to building a successful business.
Get launched, get feedback, and get going!
— Matt Morris, The Imperfect Builder