Essay
Northline Editions / 2026
What Happens When a Small Team Chooses Its Own Software Stack
An essay on the real trade-offs a small team takes on when it chooses its own tools instead of inheriting someone else's stack.
A team of four joins an existing company and inherits a codebase, a deployment pipeline, and a set of tools nobody in the room chose. Six months later, three of those same four people leave to start something new. The first real decision they make, before a single line of product code exists, is what to build it on. Nobody hands them a stack this time. They have to choose one, and the choice will outlive most of the decisions that come after it.
This essay is about that second scenario — the one where a small team gets to pick, and has to live with what it picked.
The appeal, and the trap inside it
Choosing your own stack feels like freedom, and for the first few weeks it is. No inherited configuration to untangle, no legacy dependency nobody remembers adding, no framework version frozen in place because upgrading it once broke something nobody had time to diagnose. A clean stack is genuinely faster to build in, at first, because every decision reflects what the team needs right now rather than what a previous team needed two years ago.
The trap is that "right now" is a moving target, and a stack chosen for a four-person team building a first version rarely matches the stack a twelve-person team needs eighteen months later. The tools that felt liberating at the start — a lightweight framework, a database that required no setup, a deployment process that fit on one page — were liberating specifically because the team was small and the requirements were simple. Growth changes both, and the stack does not automatically grow with them.
This is a common pattern with database choices in particular. A document store with no fixed schema is genuinely pleasant to build against in the first month, because nobody has to agree on a data model before shipping something. By month eight, the same flexibility has become the problem: five different parts of the product store slightly different shapes of the same underlying record, because nothing ever forced anyone to reconcile them. The tool did exactly what it promised. The promise just stopped being useful once the team's real need had changed from "move fast" to "keep this consistent."
What you are buying
It helps to separate what a technology choice buys a team from what it costs them, because the two are rarely proportional in the direction people expect. A trendy new framework buys velocity today and a smaller hiring pool tomorrow. A boring, well-established one buys slower initial development and a much easier time finding people who already know it.
| Factor | Newer or niche tool | Established, boring tool |
|---|---|---|
| Learning curve for the current team | Often low, if the tool was chosen because it fit their existing habits | Sometimes higher, if nobody has used it recently |
| Hiring pool | Narrow; candidates are rare and often expensive | Wide; most relevant candidates already know it |
| Documentation and community support | Thin, scattered across forums and source code | Deep, with established patterns for common problems |
| Long-term maintenance risk | Higher; smaller tools change direction or lose support faster | Lower; large ecosystems move slowly and predictably |
| Initial development speed | Often faster, if it matches the problem well | Often slower, more boilerplate |
None of this is an argument for always choosing the boring option. A tool that fits the actual problem well is worth some hiring friction. But teams rarely make this trade-off consciously. They choose the tool that was interesting to learn, and only notice the hiring cost a year later, when a job posting sits open for months because almost nobody has the specific combination of skills the stack now requires.
The table above simplifies a real decision into five rows, which is useful for spotting the trade-off but dangerous if it is treated as the whole analysis. A niche tool with thin documentation can still be the right call if the problem it solves is itself niche — general-purpose, well-documented tools are not always general-purpose enough for a genuinely unusual requirement. The row that matters most tends to be the one that is hardest to fill in honestly: how much of this project's difficulty lives in the part this tool is meant to solve, versus how much of the appeal was simply that the tool was new.
The maintenance tax nobody budgets for
Every tool a team adopts becomes something somebody has to keep working. Dependencies need updating. Security patches need applying. Breaking changes in a library's next major version need absorbing, usually at the least convenient moment. This is true of boring tools and exciting ones alike, but the tax is more predictable with the boring ones, because more people have already paid it and written down what it cost.
Small teams tend to underweight this because the tax is invisible during the exact period when the stack decision gets made. Nobody budgets time for a dependency upgrade that is eighteen months away. The team that will eventually pay that tax often is not the team that chose the tool — turnover being what it is — which means the incentive to choose conservatively is weakest exactly when the decision is being made.
There is a reasonable middle position here, and most experienced teams find it by trial rather than by reading about it in advance: choose unconventional tools for the parts of the system that are genuinely novel to your problem, and choose boring, well-supported tools for everything else. The novel part deserves a tool built for it. The parts that every product needs — authentication, data storage, deployment — rarely benefit from novelty, and the maintenance tax on those pieces compounds the most, because they touch everything else in the system.
This division sounds obvious stated plainly, and it is routinely ignored in practice, because the boring parts of a stack are the least fun parts to build, and a small team choosing its own tools is usually choosing them partly for enjoyment as well as fit. That is not a flaw to be ashamed of — a team that dreads its own tools will build worse software than one that enjoys the work — but it is worth being honest about which decisions were made for the product and which were made for morale. Both are legitimate. Only one of them should be applied to the parts of the system a future hire will need to trust without asking questions.
Choosing with the next hire in mind
The healthiest version of this decision treats the stack as a hiring decision as much as a technical one. A four-person team choosing tools is implicitly choosing who can join them next, and how steep that person's first month will be. A stack built entirely from tools only the founding team understands is a stack that only the founding team can maintain — comfortable until someone leaves, and genuinely risky after that.
None of this argues for timidity. It argues for treating each unconventional choice as a specific bet, made deliberately, rather than as the accumulated residue of what happened to be interesting to learn at the time. A team that can name its bets, and explain why each one was worth the maintenance tax it will eventually owe, tends to end up with a stack it can actually live in — not just one it enjoyed building.