The quote for more cores usually arrives before anyone has profiled anything. Sometimes the hardware really is the constraint — but far more often it's one unindexed query, an N+1 loop, or a batch chain that has run serially since 2009 for no reason anybody remembers. Those don't get faster when you pay more. We measure first, then change one thing at a time.
There is a usual cause behind each of these, and it is rarely the one the invoice is for.
A quote for more cores arrives before anyone has profiled anything. Sometimes the hardware really is the constraint — but that should be a finding, not an assumption.
It used to finish by four. Now it lands at seven, month-end lands later still, and somebody starts every morning checking whether yesterday actually closed.
Everyone knows which one, and everyone knows to run it after hours. Nobody has ever looked at its query plan. That's a workaround the business quietly agreed to keep paying for.
Instances sized during a panic two years ago are still running mostly idle, next to environments nobody has logged into since. Nobody owns the bill, so nobody asks what's on it.
Fine at ten, unusable at two. Intermittent is usually contention — blocking, a queue, or a scheduled job nobody has connected to the complaint yet.
Diminishing returns are the signature of a single-threaded step or a lock, not of a machine short on capacity. More cores cost real money and change nothing anybody notices.
A baseline goes in writing before anything changes, and the same numbers get taken again at the end — including anything that got worse.
Measure before you change anything — otherwise it's a guess with a budget.
Where most 'we need a bigger server' conversations quietly end.
For the overnight window that grew past the night.
Rightsizing, and switching off what nobody has opened in a year.
Tuning has a ceiling, and it's worth naming up front. A large win on a job that runs monthly, overnight, with nobody waiting on it changes nothing anybody can feel — so work here gets ranked by its effect on the queue people are actually standing in, never by the size of the multiplier.
The other limit is work that shouldn't exist at all: the report with no readers, the approval step added after an incident in 2014, the file exported nightly so one person can ignore it. Waste that sits in the process rather than the code gets cleared more cheaply by a Lean Six Sigma pass. And where the design has genuinely run out of road, or the constraint lives inside a vendor product nobody can change, that goes into the report as the finding.
Then tuning is the second job. Code rescue — a safe build, a safe deploy, and a net that catches regressions — is the first.
Reports that crawl are far more often a semantic model problem than a capacity one. That's Power Platform work, not a hardware purchase.
Occasionally the design really has run out of road. We'll say so — and build the replacement only if the measurements justify it.
Our project write-ups cover what the constraint turned out to be and what changed — without the client logos.
Maybe — but that should be a conclusion, not an opening move. Hardware fixes a genuine shortage of capacity. It does very little for a missing index, a lock, or a batch chain that runs serially for no reason, because none of those scale with cores. We measure first and tell you which one you have, and when the hardware really is the constraint you get that in writing too.
Then you get told that. If the constraint is inside a vendor product nobody can change, if the design is already close to what it can do, or if the slow thing runs once a month while nobody waits on it, there is no engagement worth selling you. Saying that costs us a project and saves you one, which is the trade we would rather make.
The same measurement, taken before and after, over the same workload. We record the baseline first — batch durations, query times, throughput, and where it matters the monthly bill — and the closing document compares against it, including anything that got worse. Without that pair of numbers, nobody can tell tuning apart from luck.
That's most of what we do. We start from the running system — its plans, logs, counters, and schedule — rather than from documentation that may not exist. If the code turns out to be genuinely unsafe to change, with no tests and one person who half-remembers it, that's a code rescue problem first and we'll say so before touching anything.
Often less than you'd expect. A good share of the wins sit outside the code: an index, a schedule change, a config setting, a connection pool sized for a smaller world. Where code does have to change — an N+1 query, a chatty interface, a cache that was never there — we keep the change small and reversible, and it goes through your normal review and release process.
Then we start at the bill. Rightsizing against measured utilization, reserved capacity for what genuinely runs year-round, and a hunt for the environments, volumes, and licences nobody has touched since the person who created them left. Worth remembering that the cheapest optimization is deleting work nobody needed: before tuning a report, check who still reads it.
How long does it take today, and who is standing around waiting on it? We'll say where the time is probably going, and what measuring it properly would take.
