Pick the stack you can still maintain in 2030

Every couple of months, somebody on the team — usually but not always junior — comes to me with a proposal that goes something like: "we should rewrite this in [Go / Rust / Elixir / FastAPI / serverless / a microservice]." They have a benchmark, a blog post, and a strong opinion.

I usually say no. Often I say no to my own version of the same proposal, six months after I had it.

We ship most of our work on Django, Postgres or MySQL, Next.js, and a few EC2 instances on AWS. The stack is older than I am as an engineer. It is not exciting. It is also the reason we can ship things that still work in year five.

This post is about why I keep picking the boring stack on purpose, and why a senior engineer's job is, more often than they expect, telling smart people no.

The cost of "modern"

When you rewrite a working system in a newer technology, you pay four costs:

1. The rewrite itself. Two engineers for three months, minimum. Often more. Almost never less.
2. The new ops surface. A new framework comes with its own deployment story, observability story, debugging story, and on-call story. Your senior engineers know these for the old stack. They have to relearn for the new one.
3. The hiring pool. "Has shipped Django to production for five years" describes a lot of engineers. "Has shipped FastAPI on AWS Lambda with their own auth layer for two years" describes very few. The newer the stack, the smaller the pool of people who can take over your code when you leave.
4. The reset of every workaround. Every old system has accumulated workarounds — the weird thing you do to handle a specific edge case from a specific client, the comment that says "do not delete this query, the parser breaks without it." A rewrite forgets all of them. You will rediscover them, in production, one at a time.

That's the price tag. The benefit, usually, is "30% faster on this benchmark." Sometimes "easier to reason about." Sometimes "the team will be happier."

I've never seen any of those benefits exceed the four costs above. Not once.

When the boring stack actually breaks

To be fair: there are cases where the older tool is genuinely the wrong tool. Three I've seen:

1. Concurrent socket handling at high scale. Django's async story is improving but it's not what I'd choose for a websocket-heavy chat product handling thousands of simultaneous connections per server. Pick something built for it.
2. CPU-bound numerical work. If you're doing real ML inference, real image processing, or real cryptography in the request path, Python is wrong. Move that work into a service in a language that fits.
3. The thing the framework genuinely cannot do. If your product needs a feature the framework has no way to provide, after you've actually checked, then yes, you need a different framework.

The pattern: switch when there is a specific, named, demonstrated problem the current stack cannot solve. Do not switch because a new thing exists.

The mistake every engineering team makes is in the "demonstrated" word. Most rewrites start with "this would be cleaner in X," which is not a problem. That's an aesthetic preference. Aesthetic preferences are not a budget for two engineer-months.

What the boring stack buys you

The reason I keep picking Django and Postgres and Next.js, in 2026, is not that they're the best at any individual thing. They aren't.

It's that they're predictable. Every problem I'm going to hit with them, I have already hit before. Every error I see, I have already seen. Every weird interaction between framework versions, I've already debugged. Every hire I make can be productive in week one, not week eight.

The technical term for this is "low ceiling, high floor." The peak performance you get from a boring stack is lower than you'd get from a perfectly-tuned modern stack. The minimum performance you get from a boring stack is much higher than the minimum you get from anything new.

Most products don't need the ceiling. They need the floor.

The microservice question, specifically

The single most expensive bad decision I see early-stage teams make is: "we should split this into microservices."

The pitch is always the same: independent deployability, team scalability, fault isolation. These are real benefits. The cost is more than people admit:

• You now operate N services, each with its own deploy pipeline, monitoring, and on-call story.
• Every cross-service call is a network call, with retries, circuit breakers, and timeout tuning.
• Every cross-service transaction needs a saga or a two-phase commit you have to operate.
• Every refactor that crosses a service boundary now requires coordinating two repositories, two deploys, and two teams.

For a 30-engineer team shipping a single product, this is malpractice. The benefits don't materialise until you have multiple teams who genuinely cannot deploy their work without stepping on each other. We don't, for any product I've shipped.

The right shape for most products, until it actually hurts, is a single Django app with internal module boundaries that one team can keep in their head. When it stops fitting, you'll know — not because you read a blog post about it, but because deployments take 40 minutes and engineers are stepping on each other's toes.

That's the moment to split. Not before.

What I'd tell a younger me

Resume-driven development is a real thing and it kills products. Every "I should learn this technology" impulse is fine on a side project and dangerous on a production system.

The discipline a senior engineer develops is the ability to want to use the new tool, recognise the want, and choose the boring tool anyway, because the boring tool means the system still works in three years when somebody else is on call.

The hardest answer to give a smart engineer is "no, we are not rewriting it." It is also the answer that, more than any single technical decision I've made, has kept the products I'm responsible for alive.

---

Md. Tausif Hossain leads engineering at DevTechGuru, a Bangladesh-based agency shipping HealthTech, PropTech, and enterprise SaaS products to clients in nine countries. He also runs TechnicalBind, an independent software studio, and teaches advanced full-stack engineering at Ostad. Reach him at tausif.bd or @tausif1337.