I am going to argue for boredom. Specifically, that for the vast majority of growing companies, the right technology is the boring one: proven, widely used, a little unexciting, and easy to hire for. The boring tech stack benefits are exactly the ones nobody puts on a conference slide, which is precisely why they get undervalued when a team is choosing what to build on.

The pull toward exciting technology is strong and usually comes from a good place. Engineers want to work with the newest thing. It is more fun, it looks good on a resume, and it genuinely feels like progress. I have felt it myself for fifteen years. But there is a difference between what is fun to build and what is wise to run, and as the person who often gets called when a system is broken and nobody can figure out why, I have seen which one you regret.

The core idea is simple. Your innovation budget is finite. Spend it on the product that makes you money, not on the plumbing that nobody will ever thank you for.

Boring means the failure modes are already known

When you choose a technology that has been used by millions of teams for a decade, you are not just choosing the tool. You are choosing every problem other people have already hit and solved. Search any error message and you find twenty answers. The sharp edges are documented. The scaling gotchas are known.

Choose the exciting new thing and you become the person discovering those problems in production, at 2am, with no Stack Overflow answer and a library maintained by three volunteers who are asleep in another timezone. Boring technology has boring, predictable failures. Exciting technology has exciting, novel failures, and "exciting failure" is the last thing you want between you and your customers.

You can actually hire for it

This is the argument that matters most in a market like Indonesia, and it gets ignored constantly. When you pick a mainstream stack, you can hire from a deep local pool. When a developer leaves, you replace them in weeks, and the new person is productive fast because they already know the tools.

Pick something exotic and you have quietly built a hiring trap:

  • The pool of people who know it locally is tiny, so you pay a premium and wait months.
  • When your one expert leaves, the knowledge leaves with them.
  • Onboarding anyone new means teaching the technology and the product at the same time.

I have watched a company get held hostage by a single developer because they were the only person in the building who understood the unusual framework the previous team chose to pad their resumes. That is not a technology problem. It is a business risk with a technology cause.

Boring survives long enough to matter

Software you rely on needs to still be supported in five and ten years. Boring, mainstream technology has that longevity almost by definition, because so many companies depend on it that it cannot quietly die. The exciting framework that everyone loved two years ago may already be abandoned, leaving you on a foundation nobody maintains.

This ties directly into how much technical debt makes your app slower to fix over time. An exotic or abandoned dependency is one of the fastest ways to accumulate the kind of debt that has no clean payoff, because eventually you are forced into a painful rewrite just to stay on supported ground. Boring choices age gently. Exciting ones often age into liabilities.

When exciting is actually the right call

I am not a Luddite, and I do not want to pretend the answer is always "use the oldest thing." Sometimes a newer technology genuinely earns its place. The test I apply is honest and specific:

  1. Is this a core differentiator? If a new technology is what actually makes your product better than competitors, spending innovation budget there is correct. That is the product, not the plumbing.
  2. Is the pain real and current? If your boring stack is genuinely blocking you today, not hypothetically someday, that justifies a move.
  3. Can you hire and support it? If adopting it means one irreplaceable person, the answer is usually no, no matter how good the tool.

The rule of thumb: be adventurous in the one or two places that make you money, and relentlessly boring everywhere else. A company that is exciting in its database, its hosting, its framework, its build tools, and its message queue all at once has not innovated. It has just signed up to debug five novel systems simultaneously.

Boring is a gift to your future self

Here is the reframe I leave owners with. The person who suffers or benefits from today's stack choice is your future team, including a future version of you, dealing with this system under pressure two years from now with different people. That future team will not care that the stack was fashionable in 2023. They will care whether they can hire for it, find answers for it, and fix it fast when it breaks.

Boring technology is a decision made in favor of that future team. Exciting technology is often a decision made in favor of today's enthusiasm, paid for by people who are not in the room yet.

This is also why technology choices belong in your broader planning, not just in a developer's preference. I have written about why your business needs a technology strategy, and stack selection is one of the clearest places where a strategic lens beats a fashionable one.

Practical takeaway

When your team proposes a stack, ask three questions: Can we hire for this locally? Will it still be supported in five years? Is the excitement about the product, or about the tools? If the answers point toward proven and mainstream, resist the pull toward novelty. Spend your finite innovation budget on what makes you money, and let everything else be reassuringly, profitably boring.

If you want an outside read on whether a proposed stack is a sound long-term bet or a resume-driven risk, that kind of technical judgment is part of what I bring to partner engagements. Start on the partner page.