Scalability assessment in due diligence: will it hold at ten times the load
A scalability assessment before an investment answers one question: does this system hold at the growth the deal is underwriting? Elegance is beside the point, and so is whether it matches how we would have built it. The investment case assumes some multiple of today, usually around ten times, and the platform either carries that plan, carries it with defined interventions, or quietly requires a rebuild the model never priced.
That last case is the one worth paying to find. A platform that needs a rewrite at 10x is a different asset: the same revenue, minus six to twelve months of roadmap, plus a hiring plan nobody budgeted.
A scalability assessment starts from the growth plan
Ten times the load means nothing until you say ten times what. Ten times the users stresses different parts of a system than ten times the data volume, ten times the tenants, or a move upmarket into enterprise accounts. We have read systems that would sail through 10x consumer traffic and buckle under their first three enterprise customers, because one tenant with a million records broke every query pattern the product grew up with.
So the first hour of the assessment goes to the investment thesis, before anyone opens the code: where growth is supposed to come from, over what period, with what shape. Then we look for the specific bottlenecks that shape hits first. An assessment that ignores the plan produces generic findings, and generic findings do not move deals.
Where systems break
After enough of these reads, the failure points are predictable. The database comes first: a single primary doing everything, missing indexes nobody noticed at current volume, multi-tenant data in one schema with no isolation story. Database problems are also the expensive ones, because fixing them under load is surgery on a running patient.
Then the work that happens off the request path: background jobs, queues, batch processing. These fail silently at scale, backing up for hours before anyone notices, and they rarely appear in architecture diagrams. Third-party dependencies come next: rate limits on external APIs that are invisible at current volume and become a hard ceiling at five times more.
AI products add a failure mode of their own, and it is economic. Classic software gets cheaper per user as it scales. An LLM product’s inference cost scales roughly with usage, so a plan that multiplies usage by ten multiplies the model bill with it, unless someone engineered the cost curve. We look for the practices described in what your AI bill looks like at ten times the volume: routing, caching, context discipline. At scale, their absence is a margin finding.
The infra cost curve is part of the read
Scalability failures are not always outages. Some systems scale technically and fail financially: the infrastructure bill grows faster than revenue, and the unit economics the deal assumed erode quarter by quarter.
So we model the cost curve next to the load curve. What does serving one customer cost today, and what are the step changes between here and 10x: the managed database tier that quintuples in price, the GPU capacity that needs reserving, the egress fees that appear when data volume grows. None of this is exotic, but it belongs in the same spreadsheet as the revenue plan, and in most deals nobody has put it there.
The rewrite question
Almost no system needs a full rewrite, and a team that proposes one deserves skepticism. The useful version of the question is: which components must be replaced on the way to 10x, when, and at what cost to the roadmap?
Most platforms need surgery rather than replacement: split the hot table, move the queue, isolate the one service everything waits on. That is normal engineering, and it gets priced as such. The finding that changes a deal is structural: a core design decision, usually around data, that cannot be fixed incrementally, where the fix freezes feature work for quarters. This is technical debt priced into the acquisition in its most concentrated form.
A useful tell: the team usually already knows. Ask what they would rebuild with six months of peace, and the structural answer comes out, often with a design doc that has been sitting in a drawer for a year. The finding then becomes the gap between that drawer and the roadmap the deal is underwriting, and it often gets confirmed in the CTO interview.
What the report says
The scalability section of our report gives a verdict tied to the plan, in one of three forms. The system holds to the underwritten growth with routine work. Or it holds if two or three named interventions happen, with an estimated cost and a timeline that must land before the growth does. Or it requires structural work that the model has to absorb, priced in months of roadmap and in money.
That verdict is one section of a full technical and AI audit, next to security, team and AI findings, because scalability is never the whole story. But when a deal underwrites growth, it is the section the investment committee reads twice.