Every new product starts with the same quiet decision: what do we build it with? In a large company that question is answered by a platform team and an approval process. In a small team it is answered by whoever is at the keyboard that evening, and the answer tends to stick for years.
We are a small team ourselves. We build six products from home in Baleshwar, and each of them needed a stack chosen for it at some point. This post is the thinking we try to apply when we make that choice. None of it is novel. Most of it is a bias towards the unexciting option, held on purpose.
Start from what the team already knows
The fastest stack is the one the team can already write in without looking things up. That sounds obvious, but it is routinely overridden by the wish to try something new.
Suppose a team of two has shipped three products in one language and framework and is now sketching a fourth. Moving that fourth product to a language nobody on the team has used in production means every problem is now two problems: the product problem, and the “how does this language handle it” problem. The second problem does not make the product better. It only makes it later.
Our rule of thumb: pick something new only when the familiar tool genuinely cannot do the job, not when it merely does the job less elegantly.
Prefer boring, well-documented tools
“Boring” is not an insult here. A boring tool is one that has been around long enough that its sharp edges are known, its failure modes are written down, and its answers are already on the internet. When something breaks late at night, the question is not “is this framework clever?” but “has someone else hit this exact error before?”
Signs a tool is boring in the good sense:
- Its documentation has been stable for years and covers the unhappy paths, not just the quick start.
- Searching an error message returns answers that are still correct.
- The major-version upgrade path is documented and has been walked by many people before you.
- It is used by organisations far more conservative than you.
Signs a tool is new in the expensive sense:
- The docs are a README and a chat server.
- Breaking changes arrive in minor releases.
- The examples online are for a version that no longer exists.
Novel tools can still be right. But every one you adopt should have to earn its place by solving a problem you actually have, today, that the boring option cannot.
Count the real cost of novelty
Novelty has a cost that arrives after adoption, not before. A new database, a new build system, a new framework — each one adds:
- Learning time, paid up front by everyone on the team.
- Debugging time, paid whenever the tool’s abstractions leak.
- Upgrade time, paid every time the project changes its mind about its API.
- Explanation time, paid whenever a new person joins and asks “why this?”
None of these appear on the day you choose. They appear over the following couple of years, which is exactly when a small team is least able to spare them. A tool that saves a week at the start and costs a day a month afterwards is a bad trade within a year.
The “one new thing” rule
A habit we find useful: allow at most one unfamiliar component per project. If you are trying a new database, keep the language and framework familiar. If you are trying a new framework, keep the database familiar. With two unknowns, you cannot tell which one broke.
Think about who you will be able to hire
A stack is also a hiring decision. When you eventually need a third or fourth engineer, the pool of people who can be productive in your codebase in their first week was set by what you chose years earlier.
Mainstream languages and frameworks come with a large pool of people who know them, a large body of learning material for those who do not, and a job market that makes people willing to learn them. A niche stack narrows all three.
This matters more in a smaller city than in a large one. If the people you are most likely to hire are nearby, or fresh graduates, the sensible stack is the one those people are likely to already know or be able to learn from freely available material.
Match the stack to the product, not the other way round
Not every product needs the same thing. A site that reviews books and films has different needs from a marketplace where people list, message and trade. One is mostly reads and text; the other is accounts, state and notifications. Using the same heavy stack for both out of habit is as much a mistake as using something different for each out of curiosity.
The questions we find worth asking before anything else:
- Is this mostly pages or mostly transactions?
- Does it need to work on slow connections and inexpensive phones?
- Will one person maintain it, or several?
- How long does it need to live?
The last one is underrated. A product you intend to run for years should use something you expect to still be maintained in years.
Keep the number of moving parts small
Every service, queue, cache and runtime you add is another thing that can go down, another thing to back up, another thing to secure, and another thing to explain. For a team working from home without a dedicated operations person, the cost of each extra component is borne directly by the people writing the code.
A single well-understood database, a single application runtime and a single way to deploy will carry most products a long way. Add the queue when you have a queueing problem, the cache when you have a measured performance problem, the second language when the first has demonstrably run out. Adding them in advance is planning for a scale you may never reach, at the expense of the scale you are at.
When novelty is worth it
None of this means never trying anything new. It means being honest about why. Good reasons include:
- The familiar tool cannot do what the product needs, and you have checked rather than assumed.
- The new tool removes an entire category of work rather than just making one task nicer.
- The team has time set aside to learn it properly, on something low-stakes, before it carries a product.
A poor reason is that it looked good in a demo. Demos are designed to hide the unhappy paths, and the unhappy paths are where you will live.
A short checklist
Before committing to a stack, we think a small team should be able to answer yes to most of these:
- Can at least one person on the team already build with it, today?
- Would the answer to an obscure error be findable without asking the maintainers?
- Could we hire someone who knows it, or teach someone from public material?
- Is there at most one unfamiliar component in the whole system?
- Does it fit the product’s actual shape rather than an imagined future one?
- Would we still be comfortable maintaining it in five years?
If the honest answers are mostly no, the exciting option is probably the wrong one. The unexciting option will not make for a good conference talk. It will, more often than not, make for a product that is still running.
