CTO or operations lead at a growing business
“The site crawls exactly when we are busiest, which is when it matters”
Does this sound familiar?
- Performance degrades predictably at peak hours or month end
- The database is the obvious culprit but nobody knows which query
- Restarting the server "fixes" it for a while
- Your developers say it needs a rewrite
- Costs keep rising because the answer so far has been a bigger server
What it costs to ignore
Slowdowns at peak are revenue events — they happen precisely when customers are trying to buy. Meanwhile the default remedy, a larger instance, buys months and raises the bill permanently without addressing the cause. A rewrite proposed at this point typically takes far longer than estimated while delivering no new value.
How the engagement runs
- 1
Measure before touching anything
Instrument the application and database so we can see where time is genuinely spent. Performance intuitions are wrong more often than not, including ours — so we do not guess.
- 2
Find the actual bottleneck
Usually missing or wrong indexes, N+1 query patterns, unbounded result sets, or connection pool exhaustion. Occasionally it is architectural. The measurement decides which.
- 3
Fix in place first
Indexes, query rewrites, pagination, caching layers, connection pooling. These are low-risk changes with large effects, and they are reversible.
- 4
Add caching and queues where they belong
Redis for hot reads, sessions and rate limiting. Background queues for work that does not need to happen inside a web request.
- 5
Only then consider architecture
If it is genuinely structural, you get an honest assessment with the reasoning shown — not an assertion that everything must be rebuilt.
Measure first, and mean it
The most expensive habit in performance work is confident guessing. Someone remembers a similar problem, a change is made, nothing improves, and a week is gone.
So we instrument first: request timing, slow query logs, connection pool behaviour, cache hit rates. Then we look at where the time genuinely goes. It is routinely somewhere nobody predicted.
What it usually turns out to be
In order of frequency:
- A missing or wrong index. One query doing a full table scan on a table that has quietly grown past a million rows.
- N+1 queries. The page loads fifty records, then issues one query per record. Fine with fifty rows, fatal with fifty thousand.
- Unbounded result sets. A query with no limit that was fine when the table was small.
- Connection pool exhaustion. Everything waits for a connection; the database itself is barely working.
- No caching where it obviously belongs. The same expensive query executed thousands of times for identical results.
All five are fixable in place. None require a rewrite.
When a rewrite is genuinely right
It happens. If the architecture cannot support something the business now requires — real-time where it was designed batch, multi-tenant where it was single — that is structural and no amount of tuning fixes it.
You will get that assessment with the reasoning shown. We have no rebuild to sell you, and our engineering practice treats a rewrite as a last resort rather than a first instinct.
What you get
- Before-and-after measurements, not claims
- The actual bottleneck identified with evidence
- Query, index and caching fixes applied
- Monitoring and alerting so the next regression is visible early
- A written assessment of whether architecture is genuinely the limit
Frequently asked questions
Our developers say we need a rewrite. Are they right?
Sometimes, but far less often than proposed. Rewrites routinely take two to three times the estimate, and during that period you maintain two systems while shipping no new value. We measure first. In the large majority of cases the problem is a handful of queries, a missing index, or an unbounded result set — fixable in weeks, in place. If it genuinely is architectural, we will show you the evidence rather than assert it.
Would a bigger server just solve it?
It buys time and permanently raises your bill. It is a reasonable emergency measure and a poor strategy, because most of these problems do not scale linearly with hardware — a query missing an index gets worse as data grows no matter how much CPU you add.
How quickly will we see improvement?
Measurement takes days. The first meaningful wins are often inside the first week, because missing indexes and N+1 patterns are both extremely common and fast to fix. Deeper work runs two to four weeks.
Can you work on a live production system?
Yes, carefully. Read-only measurement first, changes staged and tested, deployed with a rollback path. We do not experiment on production, and we do not need downtime for most of this work.
What if the problem is not the database?
Then the measurement says so, and we follow it — external API calls without timeouts, memory pressure, disk saturation, a misconfigured web server, or a CDN doing nothing useful. The discipline is to measure rather than pattern-match, which is exactly why we start there.
Services involved
Infrastructure & Backup
Servers, clusters and backups designed so that failure is survivable and boring.
Learn moreSoftware Engineering
Architecture, subscription platforms and data pipelines — built to be maintained.
Learn moreTell us what is breaking — or what you are trying to build.
You get a senior engineer on the first call, not a salesperson. If we are not the right fit, we will say so and point you somewhere better.
Active incident? Write “URGENT” in your message and we prioritise it.