The question usually arrives at the worst moment: a launch is booked, a campaign is about to run, or somebody senior has asked what happens if this works. It is answerable, and it is answerable cheaply, because the failures are boringly consistent across products that otherwise have nothing in common.
Is my app ready to scale?
Not if you cannot answer three questions. Which query gets slower as rows are added. What happens when your busiest dependency is unavailable. And what the bill looks like at ten times today's traffic. Most builds fail on the first, and it is usually a missing index rather than an architecture problem.
That last point is the good news and it is why this is worth checking early. The popular imagination has scale failures as architectural: you chose the wrong database, you should have built it differently, start again. Occasionally true. Far more often the fix is an index, a cache, a query that stopped selecting every row, and a limit on something that had none.
What actually breaks first when traffic grows?
The database, almost every time, through a query whose cost grows with the number of rows rather than staying flat. It is invisible at a hundred records because everything is fast at a hundred records, and it becomes the whole problem somewhere in the tens of thousands.
- After the fix
- Left alone
Illustrative, not a benchmark of your system. The shape is the point and it is why this failure is so consistently missed: at the row counts a young product has, both lines are the same line. The divergence starts at the volume that arrives with your first good week.
Growth is a process. Nothing here happens overnight, and anybody promising you overnight results is lying to you.
Check readiness from $100Second most common is a dependency with no timeout. A payment provider, an email service or a third party API has a slow afternoon, your requests queue behind it, and every worker in your pool is sitting waiting on somebody else's outage. The site is down and none of your code is broken.
Third is the thing nobody looks at until the invoice arrives: cost. Serverless functions, per-row database pricing and per-request logging are all pleasant at low volume and can go non-linear in a way that is technically working perfectly while being commercially fatal.
- Find the queries whose cost grows with row count Read the query plan rather than the code. A sequential scan on a table that will keep growing is a scheduled outage with no date on it yet.
- Put a timeout on every outbound call Then decide what happens when it fires. A default of "wait forever" turns somebody else's bad day into your downtime.
- Find the single points of failure One worker, one cron, one machine, one key held by one person. You do not have to fix them all. You do have to know which ones exist.
- Model the bill, not just the load Ten times the traffic on ten times the price per unit is a hundred times the invoice, and that arithmetic has ended more products than downtime.
- Test the busy path, not the whole system Load testing everything is expensive and mostly reassuring. Load testing signup, checkout and whatever your campaign points at is cheap and mostly alarming.
Do I need a load test?
You need one before an event with a known spike: a launch, a broadcast mention, a sale. You do not need one to answer the general question, because a review of the query plans, the dependencies and the pricing model finds most of what a load test would find, at a fraction of the cost and without a staging environment.
Load tests are also easy to run in a way that proves nothing. Hitting the homepage ten thousand times tests a cache. The useful test drives the path that writes to the database while logged in, because that is the path that has contention on it, and it is the one nobody sets up because it is fiddly.
Is a vibe-coded app more likely to fall over?
It fails in more predictable places rather than more often. Code written quickly with an AI assistant tends to be locally correct and globally unconsidered: each function does what it says, and nobody decided what happens at volume, because that decision was never a line of code anybody had to write.
The recurring pattern is that the model produced the straightforward version of every operation. Fetch all, filter in memory, no pagination, no index, no limit. That is the right first draft and a genuinely bad hundredth-thousand-row version, and the reason it survives is that it works perfectly right up until it does not.
What does a readiness check cost, and what do you get?
Ours starts at $100 for an entry check, which names the single largest scale risk in your build and what to do about it. The fuller assessment goes through queries, dependencies, failure points and the cost curve, and returns a go, fix-first or rebuild verdict with the fix list in priority order.
What you should not accept, at any price, is a verdict with no reproduction attached. "Your architecture will not scale" is an opinion. "This query does a sequential scan on a table growing by 4,000 rows a week, here is the plan, here is the index" is a finding, and you can act on it this afternoon whether or not you ever hire anybody.