Find out before the growth arrives.
The system works at today's load. The question is what happens at ten times it — and whether the answer is a tuning job or a rebuild.
We review your architecture against the growth you are actually planning, and tell you what breaks first, what it costs to fix, and what you can safely leave alone. Usually one to two weeks.
Updated August 2026
One thing gives way first.
There is always a specific constraint. Everything else has headroom.
Systems rarely fail evenly. One thing gives way first.
There is always a specific bottleneck — a database query, a single-threaded job, a service everything routes through. Everything else has headroom. Finding which one it is turns a vague worry into a piece of work with a price.
The other half is knowing what not to touch. Teams often rebuild the parts they dislike rather than the parts that will break, because dislike is easier to feel than load is to measure.
So we measure, model the growth you are actually planning, and rank what to fix by when it will hurt.
What you get.
The binding constraint, named
Which single thing gives way first at your projected load, with the evidence.
Ranked by when it hurts
What breaks at 2×, at 5×, at 10×. So you fix in the order the business needs.
What to leave alone
Often the more useful half. Teams rebuild what annoys them rather than what will fail.
Cost at projected growth
What the infrastructure bill looks like if the plan works. Rarely modelled beforehand.
Quick wins separated
The things worth doing this month, apart from the ones needing a quarter.
An honest verdict on rewriting
Sometimes the answer is a rebuild. More often it is three specific fixes, and we will say which.
A written record
Something your team can work from and your board can read.
A walkthrough with your engineers
So the findings land with the people who will act on them.
What usually gives way first.
In rough order of how often we find it is the binding constraint.
| Bottleneck | Symptom before it fails | Usually fixable by |
|---|---|---|
| A few slow queries | Pages get slower under load, not always | Indexes and query changes — cheap |
| Everything routes through one service | One deploy affects everything | Splitting the hot path |
| Background jobs run in sequence | Backlogs build at peak | Parallel workers and a queue |
| No caching where it matters | The same expensive work, repeatedly | Caching — often the largest single win |
| Database is the single point | Everything waits on it | Read replicas, then harder choices |
| The whole design | Nothing scales without a rewrite | Rare — and we will say so plainly |
Systems behind the judgement.
Card lifecycle at Pakistan's largest payment switch — load where architecture decisions show.
Payment platform reached through the banking apps most Pakistanis use.
We do not bid to rebuild what we review. It would make the finding worthless.
When to review.
You are planning real growth
A campaign, a new market, a large customer. Better to know before the traffic arrives.
It is slow and nobody knows why
Usually one or two specific things rather than a general problem.
Your team disagrees about a rewrite
An independent read settles arguments that have been running for months.
Not if it works and is not growing
A stable system under stable load does not need reviewing. We will tell you to save the money.
How we work.
We ask what growth you expect
Real numbers. Reviewing against an imagined 100× produces useless advice.
We look at the actual load
Metrics, slow query logs, where time goes now. Not the diagram.
We find what binds first
There is always one thing. Everything else has headroom.
We model the growth
What breaks at 2×, 5×, 10×, and what it costs to run at each.
We rank by urgency and cost
Including what to leave alone, which is usually most of it.
We walk your team through it
So it becomes work rather than a document.
Frequently asked.
5 questions answered. Still have one? Reach out.
One to two weeks for most systems. The work is mostly reading code, looking at real metrics and talking to your engineers — the constraint is access rather than effort. A very large platform with several teams takes three.