← All insights
Engineering

Why we still pick boring tech in 2026

· 7 min read · By METZ CODE

There's a new framework every Tuesday. We've stopped showing up to the launches. Here's why METZ CODE keeps choosing technology that's been around long enough to have known bugs.

The case against new things

The most expensive mistake in software is not "we built it wrong" — it's "we built it on something that wasn't ready." In 2026 we're still cleaning up systems that were stood up on whatever JS framework was hot in 2020. Half of those frameworks have moved twice since.

When we evaluate a stack for a new project, we ask three questions:

  1. How many production incidents has this technology survived? A library with five years of GitHub issues is a library that has been broken in interesting ways and fixed. A six-month-old library with a beautiful README has not.
  2. How many engineers can debug it on day one? Hiring is harder than picking a stack. If we pick something exotic, every new hire is a six-month ramp. If we pick PostgreSQL, every backend engineer worth hiring already knows it.
  3. Does it have a five-year roadmap from a real maintainer? "We're rewriting in Rust" doesn't count. Microsoft committing to .NET LTS for three years counts. The PostgreSQL development group has been releasing on a yearly schedule since 1996.

What we mean by boring

Boring isn't slow or ugly. It's the opposite of "we'll find out." A boring choice is one where:

  • The failure modes are documented and well-understood.
  • There's a path to scale that doesn't require a rewrite.
  • You can find six engineers in your network who've shipped it.
  • Stack Overflow has answers from 2018.

PostgreSQL is boring. Redis is boring. .NET 8 is boring. Postgres queues handle 90% of what people reach for Kafka for. TypeScript is gloriously boring — and that's exactly why it won.

When boring isn't right

We don't pick boring just to feel safe. There are real cases where the boring choice is the wrong one:

  • You're building something that genuinely doesn't fit existing tools. If your problem is "we need a real-time collaboration engine," a CRDT library with three releases is not boring — it's a research project. Reach for the genuinely novel thing here.
  • The boring tool's bottleneck is your bottleneck. If you're running ad-tech at billions of events per day, PostgreSQL isn't your tool. Pick the right specialized thing.
  • You need a feature that's only in the new thing. If you genuinely need to query embeddings at scale and you're already on Postgres, pgvector is so new it's interesting — but the alternative is a separate vector database, which is also interesting. Pick whichever is easier to operate.

The mistake isn't "we picked a new thing." The mistake is "we picked a new thing because it was new."

What we still get wrong

We're not pure on this. We've made mistakes:

  • We picked a Node.js queue library in 2021 that the maintainer abandoned in 2023. Now we're on BullMQ.
  • We tried to build on a "modern" auth library in 2022 because the spec looked clean. We rolled back to a more boring choice after two production incidents.
  • We had a brief Deno phase. Don't ask.

What we've learned: the boring tools have a property the exciting ones don't. When something breaks at 2 a.m., you can find someone on Stack Overflow who hit the exact same bug in 2019.

How we actually decide

For a new project, our default stack in 2026:

  • Backend: .NET 8 (when in EU/Microsoft-friendly orgs), Node.js + NestJS (TS-heavy teams), or Python + FastAPI (if any ML is in scope).
  • Database: PostgreSQL. Always start here. Add things only when you need them.
  • Cache and queue: Redis if you need it. Postgres queue if you don't.
  • Frontend: React + Next.js or Vue + Nuxt. TypeScript everywhere.
  • Hosting: Azure or AWS depending on team familiarity. On-premise if compliance requires it.
  • Mobile: React Native if one small team owns both apps. Native if performance/UX matters and you have native engineers.

None of this is bold. That's the point. You don't pay us for a stack diagram with seventeen logos on it. You pay us for software that's still running in five years.

What you can take from this

If you're picking a stack right now, ask three questions:

  1. Does the maintainer ship every year on a known schedule?
  2. Has the stack gone through at least one major version change without breaking the world?
  3. Could we re-staff the team in six months if we lost everyone?

If the answer to all three is yes, you're picking boring tech. Boring is the goal.