€27 a month vs Concorde: why 'grown-up' infrastructure kills 74% of startups while boring infra prints money

Concorde carried a hundred passengers and burned roughly twice the fuel of a Boeing 747 that hauled four times as many. By the end a ticket cost about $12,000 to move one body. It was retired not because it stopped flying — but because it was a converter of fuel into prestige. Your Kubernetes for two hundred users is the same plane.

The most beautiful plane in history was killed by empty seats

24 October 2003, Heathrow. The drooped-nose plane — Concorde, a British Airways jet — taxis to the runway for the last time. People gather above the terminal, some crying. This machine accelerated past twice the speed of sound; the roar of its engines was once heard on both shores of the Atlantic. An engineering masterpiece. And in two hours it will fall silent forever.

Concorde carried a hundred passengers and burned roughly twice the fuel of a Boeing 747 — which hauled four times as many people. By the end a London–New York round trip cost about $12,000 to move one body the same distance a 747 economy seat covered for a few hundred. Concorde was pulled from service not because it stopped flying. It was pulled because it was a converter of fuel into prestige: a machine that perfectly solved a problem nobody had — how to fly fast and go broke beautifully.

I keep that image in my head every time I open the bill for my infrastructure. It’s €27 a month. Six products. Eleven Docker containers on a single rented server that costs less than two pizzas. The stack looks like I stopped somewhere in 2014 and refused to move on: Postgres, Redis, a few monoliths on boring frameworks, Caddy out front, backups on cron. No Kubernetes. No service mesh. No message queue I’d stand up just to mention it on a résumé.

And I’m regularly told you can’t do it this way.

This conversation isn’t new. But in 2024–2025 it became different — not in tone, but in stakes. The GPU-cluster race, ChatGPT as the reference point for any pitch, hyperscalers reporting record revenue — all these signals fused a new norm: if your infra “doesn’t look like an AI company”, you aren’t taken seriously. At the same time the post-ZIRP FinOps movement started publicly counting what that norm had cost over the previous five years. The answer was uncomfortable. The pressure to “look like a cloud giant” didn’t vanish — it sharpened. But now it competes with a counter-pressure: bills you have to pay in a world where zero rates are gone and so is the free money for “beautiful architecture”.

The architecture astronaut and his sympathetic smile

I have an antagonist. He isn’t a villain — he’s worse, he’s pleasant. Call him the Architecture Astronaut: a senior engineer in a hoodie who, reviewing my MVP for two hundred users, looks at the diagram, tilts his head slightly, and says with faint sympathy: “This won’t scale.”

He has never — not once in his entire career — asked how many users need scaling. The number doesn’t interest him, because the number would ruin the performance. Instead he picks up a marker and draws a service mesh, Kafka and three Kubernetes clusters for an app that is essentially a to-do list with a save button. He isn’t building my product. He’s building his résumé for the next FAANG interview — a résumé I pay for. It’s a tender where the winner already sits on the committee, and the winner’s estimate has my company as a line item.

And here’s my personal stake, which I lay out early, because without it this text is a lecture, and I have no right to lecture. At two in the morning the Architecture Astronaut stops being external. He climbs into my head and speaks in my voice: “Real engineers don’t do this. Look at your stack. It’s embarrassing. It’s 2014. Grown-up companies don’t launch this way.” And while that voice whispers, the €27/month infrastructure silently serves real customers who pay real money into a real account. The voice is beautiful. The bill is real. That’s the whole conflict of this essay in one sentence.

So what follows isn’t a justification. It’s an autopsy. I want to show what this shame is made of, and why it’s the most expensive emotion in engineering: the only one billed to you every month, while you say thank you.

Brooks already said it all in 1986, while we pretended not to hear

Fred Brooks, the essay “No Silver Bullet”, 1986. The man who ran development of the IBM System/360 and wrote “The Mythical Man-Month” cuts software complexity in half. There is essential complexity — the problem itself, irreducible, hard by its nature: making the product do what a person needs. And there is accidental complexity — the mess engineers invent themselves: toolchains, layers of abstraction, orchestration of orchestrators. Brooks warns: no single tool will deliver even a tenfold gain, because all the weight sits in the essence, not the wrapping.

Reread that and look at modern “infra” with new eyes. Most of it is accidental complexity sold as essential. You’re told that without a service mesh you won’t survive, as if a service mesh were a law of physics of your domain, rather than a band-aid on a problem you created yourself by cutting a monolith into sixteen pieces, each of which must now somehow find the other fifteen.

My €27 stack isn’t primitivism. It’s essential complexity with the accidental layer amputated. I didn’t economize on the problem. I economized on self-invented pain. The difference between those two sentences is the whole book.

And here’s the black joke hidden in the very structure of this amputation: every service you don’t stand up is an incident that won’t happen at three in the morning. The most reliable component of a distributed system is the one that doesn’t exist. The Architecture Astronaut sells you eight nines of reliability per node; I choose one nine on zero nodes, and it never wakes me up.

Ten engineers, half the planet, a boring stack

If the essence really is hard and the wrapping is self-inflicted, then somewhere an extreme proof must exist. It does, and its name is WhatsApp.

2014. A server room, tuned FreeBSD. A handful of engineers on Erlang — a language invented for telephone exchanges back in the ’80s, which your junior friend would write off as “grandpa’s” — holds 465 million monthly users and about 147 million concurrent connections. One box carries roughly two million open TCP connections. The whole company is a few dozen people; on the Erlang system itself, which handles both development and operations, by various estimates around a dozen engineers. In February 2014, Facebook buys this for ~$19B.

Do the ratio yourself: hundreds of millions of people per team that would fit in a minibus. Now recall the last startup you saw where fifty engineers heroically fell over at ten thousand users because their Kubernetes was in a bad mood. WhatsApp chose boring, dense, in-memory. The neighbours chose fashionable, distributed and scattered. Guess which of them slept at night, and which spent those nights building a résumé and granting the pager the right to wake them.

This isn’t a one-off. Instagram sold to Facebook for $1B in April 2012: thirteen people, six of them engineers, on a fairly simple AWS / Django / Postgres stack. The valuation-per-engineer was absurd precisely because they did not over-engineer. A thin team plus a boring stack delivers billion-dollar results again and again — that’s not an exception, it’s a pattern the industry diligently ignores, because it doesn’t sell conference tickets.

But here the hostile reader has the right to step in with the strongest objection, and I won’t dodge it. WhatsApp and Instagram are the top of the survivors’ pyramid. Most startups with lean infra also died — not from over-engineering, but because they didn’t find the product, didn’t reach the market, didn’t raise enough. Nobody writes a post-mortem: “We failed because we only had eleven containers.” A simple stack is not a magic survival recipe. And that’s a truth I’m obliged to name. But here’s what the objection doesn’t explain: over-engineered infra saved none of those who didn’t find product-market fit — it merely added one more cause of death on top of the first. A lean stack doesn’t guarantee survival. A complex stack nearly guarantees you’ll spend your last money and last month of runway on a Kafka cluster instead of a conversation with a customer. The difference between them isn’t the survival rate — it’s what you die of, and how fast.

Even Amazon publicly reverted to boring — and that’s fine

March 2023, the Video Quality Analysis team inside Amazon Prime Video. They look at the bill for their distributed serverless machine — AWS Step Functions conducting lambdas, with video frames shuttled back and forth through S3, every handoff a billable call. Beautiful architecture from the slides. Expensive architecture from the invoice. And they make a decision considered heresy in certain circles: they collapse everything back into a single monolith running within one process. The result — infrastructure costs cut by more than 90%.

Consider the geometry of this shame: a company that sells the world serverless as the future quietly switches it off at home, because its own price list turned out to be too persuasive. It’s like a chef who doesn’t eat in his own restaurant. But next I have to stick the scalpel into myself before the hostile reader does. This figure is adored and cited wrongly. The microservices consultant Sam Newman immediately noted: it’s actually a story about pricing models of functions vs long-lived VMs, with a “narrow band of applicability”. It was a serverless → monolith transition, not the classic microservices → monolith. So the 90% is real, but it doesn’t prove “microservices are evil”. It proves something narrower and more valuable: when slide-deck architecture meets the invoice, the invoice always wins the argument. Even at Amazon. And reverting to boring isn’t a defeat — it’s adulthood.

I deliberately present this fact with a caveat, because my thesis isn’t “complex bad, simple holy”. My thesis is that complexity must be earned by load, not written to yourself in advance against a future that, with 74% probability, won’t arrive. We’ll get to that 74% now.

Flash correlates with death, not neutrality

Here’s the fact that turns the whole conversation from aesthetic to clinical. Startup Genome studied over 3,200 high-growth tech startups. Among those that died, 74% died from premature scaling — over-investing in team, spend or tech before finding product-market fit. No startup that scaled prematurely crossed the 100,000-user mark. And those who held their pace grew roughly 20× faster than the hasty ones.

Reread the key part: 74%. Not a lack of vision. Not a hostile market. Not a competitor with a bigger budget. The number-one mechanical cause of death is building too big too soon. And over-engineered infrastructure is premature scaling that put on an engineering hoodie and passes itself off as technical maturity. A service mesh for two hundred users isn’t a margin of safety. It’s a noose you weave for yourself while the voice at two in the morning says you’re finally doing it “like a grown-up”.

Fancy infra isn’t neutral. It actively correlates with a startup’s death, not its survival.

This is the nail the whole text was written for. The Architecture Astronaut sells you complexity as insurance. The data says you’re buying poison in a vitamin wrapper. And the worst black joke in this autopsy: you pay for it twice — first in the time and money to build it, then in the company itself, when it dies because you heroically prepared it for a load that never came. It’s the only insurance in the world that kills the exact object it insured.

The FinOps paradox: hype doesn’t cheapen infra, it turns waste into a subscription

“But the cloud optimizes itself,” the optimist will say. No. Per Flexera’s State of the Cloud reports, cloud-budget waste stubbornly holds at roughly 27–32% every year since 2019. Organizations themselves estimate they throw away about a third of cloud spend; 84% name managing cloud cost their top headache.

Consider the stability of that figure. A decade of FinOps conferences, an army of dashboards, a whole new profession of “cost optimization engineer” — and the waste margin hasn’t budged. This isn’t a bug of the industry. It’s its business model. Hype doesn’t make infra cheaper. Hype turns waste into a subscription that auto-renews every year, and bills you for the privilege of believing that this year you’ll finally tame it. A third of the money burns in the background as steadily as my Postgres runs — except Postgres at least charges nothing for it.

Now the opposite pole. In 2022, 37signals (Basecamp, HEY) found an annual AWS bill of over $3.2M. They bought Dell servers for roughly $600–700K, left the cloud — and the annual bill dropped to ~$1.3M. Savings of about $2M a year; the hardware paid for itself in under eighteen months; five-year savings are now projected at over $10M. The “modern” default turned out to be the expensive option. The “old” one — owning your boxes — turned out to be the smart one. Anti-hype, converted into two million dollars a year.

You only have three tokens. Don’t spend them on plumbing

So why do we still buy in? Dan McKinley, the essay “Choose Boring Technology”, 2015. His model is simple to the point of cruelty: imagine every company has about three “innovation tokens”. One token on a fashionable database. One on an exotic queue. One on a shiny orchestrator. And that’s it, the budget is spent — you burned all three on plumbing, and none is left for the product that actually differentiates you from a competitor.

Boring technology wins not because it’s better in itself. It wins because its failure modes are already known. When Postgres breaks, in thirty seconds you find the answer that millions found before you. When your fashionable distributed graph engine version 0.7 breaks, you find one GitHub issue — opened by you, with no answers — and at three in the morning the maintainer himself appears under it to write: “weird, we can’t reproduce that.” That’s your entire round-the-clock support: a stranger who’s also curious why it’s on fire.

Eleven containers of boring beat three containers of exotic. The hype tax is paid with the very tokens you needed for your real business — and it’s paid up front, in cash, before the first customer for whom you supposedly started all of this even shows up.

And also: 64% of your features will never be opened by anyone

In here too — the product side. The infamous Standish figure: 64% of features in software are “rarely or never used” (7% always, 13% often, 16% sometimes). It must be used with a scalpel, not a sledgehammer: it traces back to Jim Johnson’s talk at the XP 2002 conference and is based on only four internal apps, unreviewed. So I flag the precise “64%” as folklore. But the direction is confirmed by a far larger sample: Pendo, across hundreds of clients, found ~80% of features rarely or never used (56% “rarely” + 24% “never”).

If it’s true of features, it’s true of your infra’s services too. Most components you’re advised to stand up “just in case” are Concorde’s empty seats. They look good in the flight plan and carry not a single passenger — yet they reliably eat fuel, because an empty seat has weight too. Every container you didn’t launch isn’t a hole in the architecture. It’s a bug that won’t happen at three in the morning, and a bill that won’t arrive at the end of the month.

A tool: the “token or debt” matrix

Enough philosophy — here’s the scalpel in your hands. Before adding any fashionable component, run it through this table. If a row lands in the right column, you’re building a Concorde.

Question for the component	Green light (essential)	Red light (accidental / flash)
Who suffers today without it?	A real paying user, with a face and a ticket	A “hypothetical million users” in the future
How many innovation tokens does it eat?	Zero — it’s boring and proven for years	A whole token on flash that isn’t in the product
Do I know its failure modes?	Yes; Googled in 30 seconds, a million answers	No; I learn them for the first time at 3 a.m. live
Whose invoice does it inflate?	Almost nothing beyond what’s already there	A separate line item on the invoice every month
Whose résumé does it actually decorate?	No one’s — it just works and stays quiet	The Architecture Astronaut’s at his next interview
What happens if I don’t add it?	Nothing; the product works, the customer pays	”Nothing” — the scariest answer for flash

There’s one rule: if the honest answer to “what happens if I don’t add it” is “nothing”, then add nothing. The cheapest infrastructure is the one you had the courage not to build.

Before the finale, it’s worth naming who doesn’t want this matrix to exist. AWS earns on over-provisioned workloads: the more reserved instances, the higher the operating margin. The senior architect grows the weight of his CV with every line of “Kubernetes” or “Event-driven architecture” — and that weight doesn’t depend on whether it was needed in that particular project. Consulting bills for complexity: a simple system is paid for in one week, the “right architecture” in several months. All three have an interest in keeping the matrix row “whose résumé does it decorate” invisible. Who pays? The founder with nine months of runway, the underfunded team that hires a senior engineer and politely listens as he draws them a Concorde on the whiteboard — and politely doesn’t ask how many tickets were sold.

Who actually holds the ocean

The counter-figure to my Architecture Astronaut is Pieter Levels. He holds a portfolio of products that, by his own account, makes about $3M a year, solo, with zero hires, on vanilla PHP, jQuery and SQLite, from one VPS. RemoteOK, they say, isn’t far from a single index.php. The revenue here is founder-stated, unaudited, so take the dollars with caution; but the stack is well documented, and it’s the same stack a senior engineer would tear apart in code review. The stack people laugh at on conference stages prints money while the talk on proper architecture is still running.

I return to where I began — the runway at Heathrow. While Concorde taxied to its last flight under the tears of photographers, nearby, on the adjacent runways, boring, ugly, subsonic low-costs took off one after another and carried all the real passengers — those who just needed to fly, not to photograph a drooped nose. Concorde got the ovation. The low-costs got the revenue.

Your Kubernetes infrastructure with six queues and a service mesh for five hundred users is a Concorde. It’s beautiful. It’s supersonic. And it carries empty seats over the ocean while the neighbour on eleven containers at €27/month ferries everyone who pays, and earns.

And that voice at two in the morning whispering “real engineers don’t do this”? Now I know its name and what it wants. It wants me to build a beautiful dead plane and call it maturity. It isn’t my conscience. It’s the in-house HR department of the Architecture Astronaut, trying to hire me into a job where I’m my own employer, my own loss, and the single passenger in an empty cabin.

My stack looks like 2014. It carries passengers. And the next time someone tilts their head and says “this won’t scale,” I’ll ask the one question the Architecture Astronaut fears most: “To how many?” Because in the silence after that question you can hear the empty seats falling.