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.

Maturity means more teams have documented operational problems and recovery methods. It reduces the number of unfamiliar failures; it does not mean every surprise has already been found.

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.

These global survey results indicate reported usage, not Indonesian vacancy counts, salaries, or candidate quality. Check local job listings and speak to potential maintainers before choosing. A widely used stack can widen the pool, but it does not guarantee an easy hire.

One language across the system

The other lever an owner controls is how many languages the system actually needs. Several languages increase onboarding needs, but do not make a system maintainable only by the original vendor. A maintainer working across all layers may need to learn several ecosystems.

Collapse that to a single language — TypeScript across backend, frontend, and scripts, say — and a maintainer can use one language across those layers, while still needing database, operations, and domain knowledge. That's the practical meaning of bus factor for a ten-person company. Bus factor measures how many departures would stall the work. Reducing specialist dependencies can help, but language count alone does not determine it.

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. A maintainer could work across those layers with one language, while still needing the relevant operations and domain knowledge.

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 estimate is not a universal percentage for every SME system. Its useful implication is to budget for maintenance as well as launch. 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? Ask what the estimate includes: access, documentation, environment setup, business rules, and testing. The duration alone does not diagnose the stack.

Closing

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

Ask a consultant who proposes a new framework to explain its benefit and maintenance plan for your 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.