What Production Actually Demands
The concerns no language teaches you and every system grows into — a companion to the Cross-Cutting Concerns part of my book, Applied Computer Science.
Where I Started
On the concerns no language teaches you and every system grows into.
You can write correct code in any language and still not have a production system. Correctness is where the work starts, not where it ends. The moment real users and real traffic show up, a different set of demands arrives — and none of them are things your language taught you.
The Concerns That Belong to No Language
A system in production has to do four things a working prototype doesn't:
- Ship continuously. Changes have to flow to users safely and often — that's CI/CD, not a heroic manual deploy.
- Be observable. When it breaks at 3am — and it will — you need logs, metrics, and traces that let you see what happened, not guess.
- Withstand hostile input. Someone will send the request you didn't expect. Security isn't a feature you add; it's an assumption you design against.
- Not bankrupt you. Cloud bills scale with carelessness. Cost is an engineering property, not an accounting surprise.
None of these belong to Python or Go or Rust. They belong to every system, in every language.
Why They Get Bolted On
These concerns share an inconvenient trait: they're invisible in the happy path. The demo works without them. So they get deferred — added after the first outage, the first breach, the first terrifying invoice — when they're far more expensive to retrofit than to design in.
Treating them as first-class changes when you think about them. Observability you can't add after you already need it. Security you can't sprinkle on at the end. Cost you can't ignore until the bill arrives. The shift is to stop treating production as a deployment step and start treating it as a set of properties you build toward from the first commit.
A prototype proves an idea can work. Production proves it can keep working — safely, visibly, and affordably — while people depend on it. That second proof is its own discipline, and it's the one that separates code that runs from systems that last.
This is a companion to "What Production Demands" (Part V: Cross-Cutting Concerns) in my book, Applied Computer Science: Production systems, built from first principles. The full part goes deep on CI/CD, observability, security, and cost — each with runnable code.