Sahil Ashar

The Case for Boring Technology

#engineering #architecture #leadership

The shiny object problem

Every engineering team faces the same temptation: use the newest, coolest technology. The Hacker News front page is always full of exciting new frameworks, databases, and architectural patterns.

But here’s what I’ve learned after 10 years of building products: boring technology is a competitive advantage.

What is boring technology?

Boring technology is proven, stable, and well-understood:

  • PostgreSQL instead of the latest NoSQL database
  • Python or Go instead of the trendy new language
  • Monoliths before microservices
  • Server-rendered HTML before complex SPAs

It’s not sexy. It won’t get you conference talks. But it will get you to product-market fit faster.

Why boring wins

1. Faster debugging

When something breaks (and it will), boring technology has:

  • Decades of Stack Overflow answers
  • Battle-tested debugging tools
  • Large communities of experienced practitioners
  • Comprehensive documentation

Compare that to debugging an issue in a framework released 6 months ago.

2. Easier hiring

You can hire engineers who already know your stack. You don’t need to:

  • Convince them to learn a niche technology
  • Spend months on ramp-up time
  • Risk them leaving for “cooler” projects

3. Operational stability

Boring technology has had its sharp edges smoothed out:

  • Known failure modes
  • Established best practices
  • Mature monitoring and tooling
  • Predictable performance characteristics

4. Focus on product

Your job is to solve customer problems, not to prove that your technology choices were correct.

Boring technology fades into the background, letting you focus on building features that matter.

When to choose exciting technology

I’m not saying never use new technology. Use it when:

  1. It solves a specific problem you actually have (not one you might have)
  2. The benefits clearly outweigh the learning curve and operational complexity
  3. You have slack to handle the inevitable rough edges
  4. It’s contained to a part of the system where failure isn’t catastrophic

A framework for technology decisions

Ask yourself:

  1. Does this solve a real problem we have today?
  2. Can we solve it with technology we already use?
  3. If not, is the new technology mature enough?
  4. Do we have the expertise to operate it?
  5. What’s the blast radius if it fails?

If you can’t answer yes to most of these, choose boring.

Real examples

Example 1: Database choice

A startup I advised wanted to use Cassandra for “future scale.”

They had 100 users.

I suggested PostgreSQL. They protested that it wouldn’t scale.

I pointed out that Instagram had 30M users on PostgreSQL before they needed to shard.

They went with PostgreSQL. It scaled fine. They focused on product.

Example 2: Frontend architecture

Another team wanted to build a complex React SPA with GraphQL.

Their app was a CRUD interface with a dozen screens.

We built it with server-rendered templates and HTMX. Shipped in half the time.

The paradox

The teams that ship fastest often use the oldest technology.

They’re not more conservative. They’re more focused.

They know that technology is a means, not an end.

Conclusion

Choose boring technology. Ship faster. Focus on customers.

You can always add complexity later. You can rarely remove it.

What’s your experience with technology choices? Email me—I’d love to hear your story.