The COVID Scaling Story That Started Diagrm
TL/DR
The Core Problem: During the 2020 pandemic surge, a major food-delivery platform survived by throwing millions at reactive cloud scaling—proving that the most expensive architecture mistakes are made months before the bill arrives.
The Industry Blind Spot: Brilliant tools exist today to deploy and monitor infrastructure after it’s running, but nothing to validate costs, risks, and scalability before we commit to code.
The AI Escalation: This problem is getting worse. In 2026, even a tech giant burned its entire annual AI budget in just four months due to a lack of architectural visibility.
The Solution:Diagrm fixes this by turning static cloud architecture diagrams into intelligent blueprints. We flag cost overruns and scaling bottlenecks at design time—when they are still cheap and easy to change.
What a Pandemic Demand Spike Taught Me About Cloud Architecture
Before I started Diagrm, I spent years as a principal solutions architect helping some of the fastest-growing technology companies in the world build and scale on the cloud. The industries varied, and the technologies changed, but a pattern kept repeating, and one experience made it impossible for me to ignore.
It was early 2020. I was working with a rapidly growing food-delivery platform. This company had spent years carefully scaling its operations and, like most successful teams, had planned for tomorrow's demand to be a bit larger than today's. Then the pandemic rewrote customer behavior overnight. Entire cities moved online at once. Demand didn't just rise; it accelerated past every historical assumption the system had been built on.
What happened next is something many engineers will recognize.
The scramble —————————————————————————————————————————————————
The infrastructure started to buckle in ways customers could feel. Orders were being lost. The application became unresponsive under load. Failure rates climbed. So we did what you do in a crisis: we scaled hard — provisioning more infrastructure and replicating large parts of the system until it stabilized. By the time it was over, the company had spent millions of dollars on raw infrastructure and on replicating a largely monolithic architecture — duplicating entire parts of the system instead of scaling only the few use cases that were actually constrained — to stay standing through the surge.
It worked. The platform recovered. By the usual measure of a production incident, it was a success — we kept the service up.
But I couldn't stop thinking about it afterward, and the questions that stayed with me weren't about that night. They were about everything that came before it.
The questions that didn't go away ———————————————————————————————————
Why had the system's scalability assumptions never been tested against a more aggressive demand scenario? Why did recovery require replicating big chunks of the architecture rather than expanding the two or three specific things that were actually constrained? Why did we only discover the real limits under live production pressure, with customers watching? And why were every one of our options reactive — things we could only do after the system was already failing?
The easy answer in moments like this is to blame the technology. The database, the queue, the cloud service, the framework. We scrutinized all of them.
The honest answer was different. So much of the energy went into the database engine — was it the right one, was it tuned correctly — when the more important question was one almost nobody had asked: how did each use case actually access data, and what transactional pattern did it really require? The system had been scaled as a single block because it had never been analyzed finely enough to scale only the parts that were genuinely constrained. The technologies were mostly doing exactly what they were designed to do. The architecture had never been examined — as a whole, and use case by use case — against the conditions it would eventually face. The decisions that determined how the system would behave under 10x load had been made months earlier, quietly, one reasonable choice at a time, and nobody had been able to see their combined consequences until the bill came due in production.
It wasn't just one company —————————————————————————————————————————
If this had been a single unlucky team, it would be a war story, not a thesis. But once I started looking for the pattern, I saw it everywhere I worked.
Cost overruns that traced back to an architectural assumption made a year before anyone looked at the invoice. Security incidents that were really architectural tradeoffs no one had revisited. Reliability problems that were design constraints in disguise. Over and over, the most expensive infrastructure outcomes weren't operational accidents. They were architectural decisions whose consequences became visible only long after the decisions were irreversible. The most expensive infrastructure decisions are almost always made months before anyone realizes they are expensive.
And here's what struck me most: our industry had extraordinary tools for the after. We could deploy infrastructure in minutes, monitor it in real time, and optimize it once it was running. What we didn't have was anything equally serious for the before — a way to actually understand an architecture and what it would cost and entail in risk, while it was still just a design and cheap to change.
Why this matters more than ever ——————————————————————————————————————
What unsettled me most afterward was how universal the pattern turned out to be — and how much worse it is getting. The same dynamic is now playing out in AI infrastructure, where a single architectural decision can shift millions of dollars in GPU and inference spending, and even the most sophisticated companies are caught off guard. In 2026, Uber's own CTO admitted the company had burned through its entire annual AI budget in roughly four months (Fortune, May 2026). If an AI-native company can be blindsided by its own spending, the problem isn't a lack of discipline. It's a lack of visibility — the same gap I watched a food-delivery team fall into in 2020, now playing out with far bigger numbers attached.
A missing layer, not a missing tool —————————————————————————————————————
The more I sat with it, the more I became convinced this wasn't a gap any single tool would close. The industry was missing an entire layer: a way to reason about and validate architecture at design time, before a decision hardens into deployed reality. Every discipline that builds expensive things already has one. Architects have blueprints they analyze before breaking ground; electrical engineers have schematics they test before manufacturing. Software infrastructure has never developed an equivalent. We learned to deploy and observe brilliantly, and we skipped the step where you understand a design before you commit to it. That missing layer — not any one product — is what I became determined to build toward.
The idea ———————————————————————————————————————————————————
That conviction is the whole reason Diagrm exists.
The question I kept coming back to was simple: what if a cloud architectural diagram wasn’t a static picture you draw and then abandon, but an intelligent blueprint you could reason about before you build? What if, the moment you placed a component, you could see what it would cost, where the risks were, and whether the design held up — and only deployed once you actually understood it?
That's what we're building. Diagrm is a place to visually design a cloud or AI architecture, see its projected cost as you go, have risks and inefficiencies flagged in the moment, and deploy only when the design is right — instead of finding out what you built after it's already running and already expensive.
I don't think that food-delivery team did anything wrong that night. They did the only things the situation allowed. The real problem was that by the time the situation arrived, every good option was already behind them. I started Diagrm so that the most important infrastructure decisions get made when they're still decisions — not after they've hardened into production.
--- Javier Navarro-Machuca, PhD — Founder & CEO, Diagrm
What's the most expensive architecture decision you've ever discovered too late? I'd genuinely like to hear your version — the stories are always more alike than we expect.
If you'd like to see what designing before deploying actually looks like, you can, Explore Diagrm
