The fastest way to a product that holds isn’t more fixes on a foundation that can’t carry weight. It’s the real version, built right, once. Here’s how I think about it, and how the work runs.
A clogged drain in a rotten house isn’t a plumbing problem. Clearing it changes nothing for long. The honest move is to rebuild the structure everything else sits on, and to start with a foundation you can keep iterating on.
A vibe-coded or no-code MVP is genuinely valuable: it proves the problem and the experience. It tells you people want this and shows what the product should feel like. That’s the hard, ambiguous part, and it’s done.
What it usually can’t do is scale. The architecture was optimised for speed to demo, not for many users, real data, tenancy or safety. So the moment the product succeeds, it starts fighting you: it slows with every user, and every change breaks something else.
At that point, patching is a trap. Each fix sits on the same foundation, and you pay for it again next month. Rebuilding to scale means keeping the proven product and experience and replacing the architecture underneath with something production-grade. Done right, the rebuild beats the original, because now you’re building with the answers the MVP gave you.
When a product won’t scale, the answer is almost never “build a new screen” or “tweak a function”. It’s two deeper choices working together: the right tech stack (the languages, frameworks and databases the product is built from) and the right infrastructure to deliver it on, how and where it actually runs.
The two are related but not the same: the technologies live on the infrastructure. Pick the wrong stack and no infrastructure saves you. Pick the wrong infrastructure and the best stack still buckles under load. Getting both right is the difference between building websites and building systems. These are the levers:
Services distributed across server solutions so the system scales by part, not all-or-nothing, and one hot path can’t take everything down.
The right store for each job (relational, vector, graph, cache) instead of forcing one database to do everything badly.
The system deployed geographically close to your users, so latency stays low wherever they are. Performance is an architecture decision.
How compute, queues, workers and data layers fit together: the part that decides whether the product holds at peak or buckles.
Picking the stack for the load and the team, not for fashion. The wrong choice here quietly caps the product for years.
Built so the next ten changes are cheap, not catastrophic. The rebuild should make tomorrow easier, not lock you into today.
What we do at each order of magnitude of concurrent users:
A clean monolith or modest split, one region, sensible defaults. Fast to ship, easy to reason about.
Caching, read replicas, queues for the heavy work. The first seams where the architecture is designed to split.
Services split along the hot paths, multi-database by job, autoscaling. Load isolated so one part can’t sink the rest.
Globally distributed, deployed near users, multi-region data. A plan that already exists on day one, not a panic later.
Note the unit: concurrent users, not total. A thousand people hitting the system at the same instant can mean a hundred thousand accounts behind them, depending on how often they show up. The point isn’t any single rung. It’s that the architecture sees all of them from day one, so each jump is a planned move, not an emergency.
Getting the foundation right is a one-way door: the architecture, the data model, the stack. Made wrong, it costs years to undo. That decision needs senior judgment, once. Iterating on top of it, shipping features, tweaking flows, is a two-way door a lighter team plus AI can walk through every day.
Plenty of people can build an app. Far fewer can establish the infrastructure underneath it and know which questions to ask at each stage. That’s the part you bring a senior in for, and then hand off. You buy senior architecture for the build, not a permanent seat for the upkeep.
The numbers back the shape. A full-time CTO is not a salary line: on payroll data from 250+ VC-backed startups (Kruze Consulting, 2024–2026), a US Series A CTO base runs roughly $200–240k, and European scaleup bases sit around €80–180k before employer costs. Add the recruiter’s cut, the months the seat sits empty, and the equity: the benchmark for a hired CTO is 0.7% in Europe and 1.0% in the US of the fully diluted company (Index Ventures, Rewarding Talent), given away on every future exit. And the search itself is the bottleneck: AI and engineering leadership is the hardest role to fill globally in 2026 (ManpowerGroup, February 2026, 41-country survey), with roughly 40% of senior searches running past 90 days.
Against that: one senior engagement, scoped and fixed after diagnosis, zero equity, nothing recurring. The platform established right, once, and handed over documented.
We live in a discount era. LLMs are cheap right now, far cheaper than what the tokens actually cost, so most builders reach for the biggest model for every job and never feel the bill. That works until prices normalise. Then a system that wastes tokens becomes expensive as hell to scale, and unprofitable exactly when it starts to win.
I build the opposite way. The rule is simple: never use an LLM for what plain executable code solves simply, and never use a more capable model than the problem needs.
Pick a model trained for the actual job, not the most famous one. The best fit for the task usually isn’t the biggest model on the leaderboard.
Most jobs don’t need a genius. A leaner model with the right tools beats a frontier model used as a sledgehammer on cost, and often on reliability.
Never reach for an LLM where deterministic code solves the problem. Systems designed to waste tokens are the quiet killer of margins at scale.
Frontier capability goes where output value is high and volume is low: crawling, synthesis, one-off analysis. Everyday queries run on lean models with the right tool use, at a fraction of the cost, every single time. That routing is deliberate, and it’s what keeps a system profitable when you scale it to thousands of concurrent users.
If two or more of these are true, you’re past the point where patching pays off.
The MVP proved the market, but growth makes it more fragile, not stronger. The architecture was never built for this.
Real data, real traffic and real edge cases are where it gives way. Fixes buy days, not stability.
AI got you a working prototype fast; now the codebase resists its own growth.
Cost, control, performance or data ownership: the platform that got you live now sets your limits.
Auth, data boundaries, tenancy, testing: the parts that decide whether you can sell upmarket.
A hire, an acquirer, an auditor. The product works; the handover doesn’t. That’s the case the engagement is scoped around.
A rebuild that only makes engineers happier is a bad purchase, and the founders who push back on rebuild quotes are right to. Your customers don’t know what your product is built on, and they don’t care. So the case for a rebuild has to be made in business measures, and it is:
This is the rebirth claim in operational form: what comes back is more than what broke, and you can measure the difference in the numbers you already track. If those numbers wouldn’t move, I’ll tell you so in the diagnosis, and you shouldn’t buy a rebuild.
Henrik Hallengren — 20+ years across product, tech, strategy and design; brands from Google to Mondelēz, worked with across roles and projects; production systems like the multi-tenant AI platform autoply built solo and running today. Independent: no platform ties, no referral fees.