Choose boring technology: picking a stack you won't regret

What “boring” actually means

Boring is not old. It means a technology that has been in serious production use long enough that its failure modes are known, its documentation is complete, its community is large, and its next few upgrades are predictable. When something breaks at 2am, the error message has ten thousand results, not two.

Boring technology is a gift to the person maintaining your product in two years, who might not be the person who built it. Every exciting, sparsely-documented choice you make now is a tax that person pays later, usually at the worst possible moment.

Stack debt vs technical debt

Normal technical debt is local: a messy function, a shortcut in one module. You can pay it down when it starts costing you. Stack debt is structural. It's an early platform decision that limits who you can hire, slows every future change, or forces a rewrite exactly when momentum should be compounding.

You can refactor a bad function in an afternoon. You cannot refactor your way out of a framework nobody wants to work in, or a database that can't do what your product now needs. That's why the stack decision deserves more care than almost any single feature: it's the one that's genuinely expensive to reverse.

A sensible default for 2026

Not the only good answer, but a defensible starting point that a lot of teams converge on because it's well-trodden:

The three over-engineering traps

Microservices before you have a monolith problem. A well-organised single application is easier to build, deploy, and debug for the first few years. Split it when a specific part genuinely needs to scale or ship independently, not on day one.

Kubernetes for ninety users. Container orchestration solves problems you do not have yet and adds operational complexity you have to carry every day until you do. A managed platform is fine until it visibly isn't.

Bespoke where a SaaS exists. Auth, notifications, search, analytics, feature flags, admin panels. Each has a mature paid option that costs less per year than a week of building the custom version, and far less than maintaining it.

Choose what the team already knows

A stack your developers know well beats a theoretically better stack they'd be learning on your budget. Familiarity compounds: fewer bugs, faster decisions, no time lost to “how does this work again.” If you're hiring an agency, ask them directly what they actually run in production and have run before. The right answer is a specific, slightly unglamorous list, not the current front page of Hacker News.

Keep it composable

Wherever you can, use pieces that talk to each other through clean interfaces and could be swapped without a rewrite. If your email provider, your search, or your payments processor can be replaced by changing one module, a wrong call becomes an afternoon's work rather than a quarter's. Composability is what makes “boring, for now” safe: you're not locked in, you're just not gambling.

Managing debt deliberately

You will take shortcuts, and you should. The discipline is to write them down. Keep a short list of the debt you've taken on, revisit it each cycle, and spend maybe 10 to 20 percent of each development cycle paying down the parts that are actively slowing you. Leave the parts that aren't. Debt that never costs you anything is just a decision you can live with.

When the interesting choice is actually right

“Boring” is a default, not a religion. Reach for the newer or more specialised option when the problem genuinely calls for it: a vector database when search over embeddings is core to the product, a specific real-time engine when live collaboration is the whole point, a particular language when the domain has strong libraries only there. The test is whether the interesting technology solves a problem you actually have today, and whether someone on the team has run it in production before. “It would be good to learn” is not a project justification.

How to change your mind later

Because you kept things composable, you can. Migrations go well when you move one piece at a time behind its interface, run old and new in parallel until the new one is trusted, and treat the switch as a series of small reversible steps rather than one big weekend. The reason to choose boring now is not that you'll never change it. It's that you want the freedom to change the one part that stops fitting, without the whole thing coming with it.

Common questions

What is the best tech stack for an MVP in 2026?

A boring, widely-used one: React (often via Next.js) on the front end, Node or Python on the back end, PostgreSQL for data, a managed auth provider, Stripe for payments, and a managed host. The specifics matter less than choosing something proven that your team knows.

What is stack debt?

An early technology choice that limits hiring, slows every future change, or forces a costly rewrite. Unlike ordinary technical debt, you cannot cheaply refactor your way out of it, which is why the stack decision deserves extra care.

Should a startup use microservices?

Almost never for a first build. A well-structured single application is simpler to build, deploy, and debug. Split out a service only when a specific part genuinely needs to scale or deploy on its own.

Is it bad to take on technical debt?

No, taking shortcuts is normal and often correct under time pressure. The mistake is not tracking it. Log the debt, review it each cycle, and pay down the parts that are actively slowing the team.

How do I evaluate an agency's technical choices?

Ask what they actually run in production and have shipped before. A good answer is a specific, slightly unglamorous list of proven tools, not the newest framework of the month.

If you want a second opinion on a stack, or an honest read on an existing codebase, send it over. Pragmatic engineering is the whole idea behind our development work.