#9: Choosing tech stacks for early-stage startups
Conscious principles to iterate fast with limited resources
I have worked with and advised dozens of startups.
From the experience of coding and managing hundreds of projects in the past ten years, I have seen many mistakes in choosing tech stacks. The mistakes can lead to reduced engineering velocity, slow yet unstable product launches, and difficulty in growing.
For example, at a project I was advising, there was a legacy product where every feature was built from scratch, using a complex technology that was very burdensome to maintain. When it was launched, it was very unstable, and the business operations virtually stopped for a week. And what followed were terrible times for everybody. A seemingly simple feature could take weeks to build. And many critical bugs spawned, giving the team nightmares.
All of those problems can arise from not picking the right tech stack.
Taking the wrong lessons from Big Tech
As technical people, we want to find inspiration from successful examples. So we read bigger Silicon Valley companies' engineering blogs. We read their tips on what shiny new technologies to use, how to solve complex problems, and how they can scale to billions of users.
Unfortunately, the technologies and practices at big tech won't work for early-stage startups. Their problems are different from yours. Their problem is scaling their technology to hundreds of millions of users and keeping productivity high with thousands of engineers. Yours are to create an iterative cycle of developing a product fast while validating it to your customers to find product market fit across those iterations.
Using fancy technologies and doing premature optimization overlooks the fact that early-stage startups have many constraints:
Very few engineers
Limited cash
Tight development timeframe
No idea whether the initial product will work out
Your goal should be to build a simple and good enough solution that your customers want to pay.
Your product may change. You may pivot. You may start over and rewrite your codebase.
More importantly, you must go through that phase quickly and many times over.
So here are four principles that will help you achieve those goals while saving time and money.
1. Choose what's popular to have an easy time hiring.
A friend of mine builds his product in a rare variant of JVM language. Let's say it's Clojure. I have no grudge against Clojure, but there are few Clojure engineers. He had a hard time hiring. When he screens candidates to hire, the chances of hitting someone with enough Clojure skills are remotely low.
Instead of rewriting his product to a more common language, he lifted the Clojure requirement. He hired engineers who may have yet to learn Clojure upfront but were open to learning it. But then, they need at least two months to get the new hire to be productive at the company.
And when a particular technology is less popular, the community and resources we can turn to for support are smaller. Let's remember the pain when we encounter a problem, and Google has nothing to show. You don't want to be the first to face a problem when you want to move fast. You want to be the 100th one, and when you encounter it, somebody has resolved it on Stack Overflow two years ago.
2. Choose what's simple and easy to maintain
Always choose simple technologies when working alone or with only a few engineers. Complex systems have an expensive toll to maintain. Understanding how they work and debugging them takes time, thus, money.
I have often seen people trying to build their first MVP by thinking they will scale to millions of users fast. Or that they need to accommodate hundreds of engineers soon. For example, one may implement a microservice architecture from the get-go. Ignoring the fact that maintaining fifteen services while only having five engineers is very hard.
Another example I observe is choosing technologies intended for later-stage companies or enterprises, for instance, Kubernetes, instead of a more straightforward one-container solution. Kubernetes may be good if hundreds of services run in a cluster of a thousand servers. But early on, you will waste considerable time setting and maintaining it.
3. Choose a framework with commoditized features to iterate fast
Many technologies, especially web frameworks, have built-in features like authentication, ORMs, or logging. Those features are commodity features. Almost every product has similar requirements. And they are rarely your product's core differentiators.
Don't reinvent the wheel. You need to invest less in commodity features so that you can invest more in your core offerings.
I have also seen teams investing many engineers in building products only two employees use. Or they are developing a whole feature that could have been a library import. With a popular excuse that their use case is different.
In my company, one of our requirements is to spawn an administrative dashboard for internal employees quickly. So we choose Django, which has it built-in, saving us months of extra work.
4. Choose SaaS when possible, then use Open Source, only then build yourself
Time is expensive in an early-stage startup, so any engineering time spent not working on your core offering is probably wasted.
In this age, where the tech ecosystems are more or less mature, there are many alternatives to building everything on your own. You can pay for an off-the-shelf SaaS solution or use open-source software rather than build one from scratch.
A few years ago, I was building a feature to do item search for an e-commerce product. And there are many possibilities to get it done:
Using a SaaS solution, like Algolia. The setup cost is pretty simple. You can get the feature running in a couple of hours.
Using an open-source solution that we need to host ourselves, like Elastic Search. It may take you a couple of days to set up and use.
Building the search feature from the ground up. While it can take weeks or months to build, the feature and performance may be subpar compared to that of Algolia or Elastic Search.
I chose the SaaS solution because it was faster to set up, easy to maintain, and relatively cheap.
Of course, you need to take into account the cost. Sometimes, we have a big technical problem where the solution is to host an open-source project ourselves instead of paying for a SaaS product. In turn, this decision saved us thousands of dollars per month. Thinking critically in estimating the cost and benefits is the key here.
–
If you want an extreme example, Pieter Levels, the famous indie founder, built and ran multiple products with only PHP and a single server setup. What's more surprising, he has millions of users and a revenue eclipsing most startups.
I'm not advocating that you use PHP or follow his engineering practice. I'm merely showing a good counterexample amidst Silicon Valley startups' overengineering.
–
Over the long term, the process and culture in your team will also matter, since choosing a tech stack is not a one-time event but a continuous process. There may be new features or products where we must make the same decision-making process. It would be best to delegate this responsibility to your team members when you have a team. So, make sure you align the principles with them.
In my teams, we require a research document and a technical design document before we embark on an adventure with new technology. After everything is written in the docs, we discuss the pros and cons of every choice. If the proposed technology is convincing enough and we are consciously aware of the trade-offs, then we use it.
So far, this practice has worked well.
Top Finds
Dan McKinley's paradigm was the inspiration to write this post. Every organization has limited innovation tokens. When you choose new technology, you use innovation tokens. And when you use too many new technologies and have negative innovation tokens, you will have a higher magnitude of unknown unknowns that you must account for.
Nancy Sherman was one of the original modern authors of Stoicism. This podcast episode discusses wide-ranging topics, such as Stoicism and the military, journaling, reducing stress, and cognitive bias.
Ted Chiang is one of my favorite sci-fi writers. In this essay, he made an excellent analogy that ChatGPT is a lossy compression of the web. Which is kinda true. When in doubt, we can ask ChatGPT for an answer, but the information may not be true. Just like a compressed photo is a representative of the original image.
Interesting - I feel sometimes a broad tech stack can also bring too much candidates with lower skills and make hiring complicated. I had personally a hard time recruiting a javascript engineer, whereas it was easy for a more specialized data engineer.