Why I Still Reach for Boring Technology

You get a fixed number of chances to be interesting. Not per project, per team. Spend one on a distributed database and you can't also spend one on an unproven queue, an experimental frontend framework, and a language nobody on the team has shipped. The budget is real, it's small, and almost every troubled codebase I've been handed spent it on things that weren't the product.

That's the whole argument. The rest is where I actually spend mine.

The budget is smaller than you think

The reason isn't that new tools are bad. Most of them are better than what they replace, on the axis their authors care about. The reason is that every unfamiliar tool costs you the same tax: nobody knows its failure modes, nobody has debugged it at 3am, the error messages don't yet mean anything to you, and Stack Overflow has four answers and two of them are from a version that no longer exists.

A boring tool has none of that cost, not because it's better, but because the cost was already paid by twenty years of other people. When Postgres does something strange, someone has already written a blog post about it. When your two-year-old vector database does something strange, you are the blog post.

Novelty is worth paying for exactly where the novelty is the product. Everywhere else you're paying for it with debugging time you didn't budget.

The defaults I reach for

Postgres for everything until it isn't enough. Relational data, obviously. But also JSONB when the schema is genuinely fluid, full-text search until you actually outgrow it, pgvector for embeddings at small scale, LISTEN/NOTIFY or a simple table for a job queue. One database to back up, monitor, and reason about. I've argued the specific case in Postgres vs MongoDB for SaaS, and my position has only hardened.

A monolith until the org shape demands otherwise. Services are an organisational solution to a communication problem, not a performance one. If you have eight engineers, you don't have that problem, you have a deployment ritual you've imposed on yourself. Extract a service when a team needs an independent release cycle.

A managed platform, not my own Kubernetes. Fly, Railway, Render, ECS, App Runner. Someone else's problem at 3am. I've written about the Kubernetes case specifically; the short version is that a cluster is a full-time job masquerading as a config file.

Server-rendered HTML wherever the page isn't an application. Most pages are documents. Documents don't need a client-side router and a state management library.

S3 or R2 for files, Cloudflare in front. No creativity required. This layer has been solved for a decade.

Cron before an orchestrator. A scheduled job that runs a script and logs its output covers a startling fraction of what people reach for Airflow or Temporal to do. Yes, retries and observability are worse. You will know when you need those, and you will not need them in month two.

Where boring loses

I'd rather concede this honestly than pretend the rule is universal.

Real-time collaboration. If multiple people edit the same document simultaneously, polling a Postgres table is not a design, it's a delaying tactic. You need CRDTs or operational transforms and a purpose-built sync layer. That's a place to spend budget.

ML inference. The tooling is young because the field is young. There's no twenty-year-old boring option for serving a model with batching and GPU scheduling. You're choosing among immature things and the only question is which immaturity you prefer.

Mobile. There is no boring choice. React Native and Flutter are both actively churning, and "just write native twice" costs more than the churn does. You have to pick a framework and accept upgrade pain as a running cost.

Anything where the boring option has a hard ceiling you can see. If you know the write volume that breaks single-node Postgres and you'll be there in nine months, choosing it anyway isn't discipline, it's procrastination.

The freelance angle

This is where the argument stopped being aesthetic for me.

I hand projects to other people. That's the job. A client's codebase outlives my involvement by years, and the question that matters isn't whether I enjoyed building it, it's whether the next developer can open it and be productive in a week.

A boring stack is legible. Next.js, Postgres, a managed host: a competent developer anywhere can pick that up, and the client can hire from a large pool at a normal rate. A clever stack is a hostage situation. When the only person who understands the custom event-sourcing layer is the contractor who left, the client's options are to keep paying that contractor or to rewrite. I've been on the receiving end of that inheritance and I'm not going to hand it to someone else.

It also changes what I can charge for. Debugging my own cleverness is not billable work I feel good about.

The time I paid for it

Early in my freelance year I built a client's job processing on a newer message broker instead of the obvious queue, because it had a delivery guarantee I liked and I wanted to learn it. It worked. Then a partition triggered a rebalance behaviour I didn't understand, jobs processed twice, and I spent the better part of two days reading source code because the documentation covered the happy path and a GitHub issue covered mine, unresolved, from fourteen months earlier.

Two days at my rate is real money, and I ate it, because I couldn't bill a client for my curiosity. The equivalent Postgres-backed queue would have taken an afternoon and I'd have known exactly how it broke.

The caveat

Boring is relative to your team, not absolute. Kafka is boring at a company that has run it for six years. Kubernetes is boring to a platform team of fifteen. Rust is boring to people who write Rust. The question was never "is this technology old", it's "does the group maintaining this already know its failure modes".

Which means the smug version of this argument is wrong. Someone else's exciting choice may be their boring one, and they'll ship faster than you on it.

The discipline isn't avoiding new things. It's being able to name, out loud and specifically, which one new thing this project is spending its budget on. If you can't name it, you're probably spending it on four.