Choosing a Tech Stack for an SME System: Boring Wins

Choosing a Tech Stack for an SME System: Boring Wins

A tech stack is a staffing decision wearing a technical costume. Almost every proposal for a small or mid-size business system talks about the technology first. How fast it renders, how "modern" the toolchain looks in a demo.

The question that actually decides how long the system survives is different. Who can you hire, locally, at a normal salary, to keep this running after the person who built it moves on?

What "boring" actually means

Dan McKinley has the clearest framing I know. In his essay on infrastructure choices, he treats new technology as a budget: "Let's say every company gets about three innovation tokens." Spend them where the technology creates a real advantage for the business. Everywhere else, use whatever is boring and proven. (Choose Boring Technology)

His argument is about risk, not taste. A mature technology mostly hands you known unknowns: problems other teams already hit, like what happens when a database maxes out CPU. A new technology hands you unknown unknowns — failure modes nobody has found yet. McKinley's own example: a team that didn't realize writing statistics would trigger garbage-collection pauses, a failure invisible until it wasn't.

Picking a doctor works the same way. A general practitioner who has seen thousands of patients knows exactly which symptoms matter and which don't. A brand-new graduate, however sharp, hasn't seen the case yet. Mature technology is that GP — its surprises were already found by someone else.

McKinley lists MySQL, Postgres, PHP, Python, memcached, Squid, and Cron as his examples of boring technology: mature, well-understood, known failure modes. Boring never means bad.

For an SME system, spend the innovation tokens on the parts of the business that actually need them. Think inventory logic, scheduling rules specific to your operation. Leave the plumbing to tools that already had their surprises found.

The local talent-pool math

"Boring" also has a direct financial reading: it's a proxy for how many developers can be hired, and at what price. The Stack Overflow 2025 Developer Survey puts JavaScript at 68.8% usage among professional developers, HTML/CSS at 63%, SQL at 61.3%, and Python at 54.8%. Bash/Shell and TypeScript tie at 48.8%. On databases, PostgreSQL leads at 58.2% and MySQL at 39.6%, comfortably ahead of SQLite, SQL Server, and Redis.

None of that measures quality. It measures the depth of the hiring pool. A stack from the top of that list means a normal job posting and a normal salary range when you need to replace someone. A stack from the survey's long tail means a narrow search and a premium rate — scarcity, not skill, sets the price.

One language across the system

The other lever an owner controls is how many languages the system actually needs. A backend in one language, scripts in a second, and tooling in a third is a stack only the original vendor's own team can maintain. End to end, everyone else has to onboard into three ecosystems just to touch one system.

Collapse that to a single runtime — TypeScript across backend, frontend, and scripts, say — and one developer can read, fix, and extend the whole thing. That's the practical meaning of bus factor for a ten-person company. It isn't about how many people know the code, it's about how many kinds of people you'd need to replace the ones who leave.

In a hotel management system I built, the backend, admin panel, and internal scripts all ran on one language. That mattered more to the stack decision than any single framework feature. One hire could keep the whole thing running, not three.

Why the newest framework is a liability for a 10-person company

Frameworks churn on a cycle far shorter than most SME systems live. Look back over a decade of front-end tooling: Backbone, Knockout, and Ember gave way to AngularJS, then React, then a ground-up Angular rewrite, then Vue. Teams that chased each wave paid for it in repeated rewrites.

A large company can absorb that churn: a platform team, migration tooling, enough engineers to run one squad on the old framework. Another squad rewrites onto the new one. A ten-person company has none of that.

When the framework a vendor chose two years ago quietly stops getting updates, there's no bench to pull from. Just a maintenance bill nobody budgeted, on a system that was supposed to be finished.

The real cost curve

Most of what a business pays for software happens after launch, not before. A peer-reviewed study on software maintenance costs found that roughly 90% of a system's total lifecycle cost sits in the maintenance phase. Some estimates run even higher. (source)

That number should drive the whole decision. A stack shouldn't be picked to look good in the launch demo. It should be picked for the years of small fixes, dependency updates, and staff turnover that follow.

Saving two weeks of build time now isn't worth six months of rewrite risk in year three. That's a bad trade, even if the demo looked great.

Questions to ask any vendor proposing a stack

Four questions do most of the work:

1. Can we hire for this locally, at a normal rate? If the honest answer is "only from our team," that's not a stack — it's a dependency on one company.
2. Where else is this running in production, and for how long? A framework with no multi-year production history is still finding its unknown unknowns. Your system shouldn't be the one that finds them.
3. What happens if you disappear? Ask it directly. A vendor confident in the answer will have already thought about it: documentation, standard tooling, no proprietary framework wrapped around the real one.
4. What does it cost to onboard a new developer to this codebase? A day is a good answer. A month is a warning that the stack, not the business logic, is the hard part.

Closing

Boring is a business decision, not a lack of ambition. The palugada instinct — the willingness to build whatever a client needs — should apply to how you deliver a project. It shouldn't apply to how many technologies you stack into it.

A consultant who reaches for the newest framework on every engagement is optimizing for their own resume, not for the ten-person company. That company has to run the result for the next five years.

Pick what's provable. Pick what's hirable. Spend the innovation tokens only where the business genuinely needs them.