We make a specific claim on every page of our site: five times faster, at a fifth of conventional cost. A claim like that needs evidence. Without evidence, it should come down.
This is the arithmetic behind the claim. It also covers the places where the arithmetic stops working.
The short version is simple. Four things got cheaper. They got cheaper by different amounts. The largest saving has nothing to do with AI at all.
A software budget pays for more than writing code
Before we talk about savings, it helps to be clear about what you were paying for. On a conventional fixed-scope build of moderate size, our own historical projects split the budget roughly like this.
- Discovery and specification, 15 percent. Working out what to build, including reading whatever exists already.
- Implementation, 40 percent. Writing the thing.
- Review, testing and rework, 25 percent. Finding out it is not quite right and fixing it.
- Deployment, documentation and handover, 10 percent.
- Project management and communication, 10 percent.
Most conversations about AI productivity focus on the 40 percent for implementation. That is the least interesting number on the list.
Writing the code is about 40 percent faster
This is the saving everyone talks about. It is real, but it is smaller than the demonstrations make it look.
Boilerplate, migrations, test scaffolding, data transformations and the first draft of most modules come out substantially faster. A person still reads and owns every line, and that reading takes time. Across recent engagements, our measured figure is around a 40 percent reduction in implementation hours, not the 10x that gets quoted.
The gap between 40 percent and 10x is review. Code produced by a model that nobody understands is a liability with a shorter fuse than code nobody wrote. The saving is real because we treat the output as a first draft by a capable but unaccountable colleague.
Understanding old systems is about 70 percent faster
This is the saving that gets less attention. On legacy work, it is the largest single saving.
Understanding a system nobody documented used to mean weeks of archaeology. Someone had to read code, trace execution and interview whoever remembered how it worked. It now takes days.
A model can read a quarter of a million lines and produce a map of what talks to what, where the state lives, and which paths are dead. It can do that faster and more completely than a person working through the system sequentially.
The map still needs verification, and we verify it. But verifying a map is a fundamentally cheaper activity than drawing one.
On utility and manufacturing engagements, systems are often decades old and the people who built them have retired. This saving alone has changed which projects are viable.
Review is about 30 percent faster
Every change gets read by a model before a human sees it. It catches the ordinary things: the missing null check, the off-by-one, the resource that is opened and not closed, and the test that asserts nothing.
That buys better reviews. Senior review time moves away from spotting typos and into arguing about design, where it was always valuable. The saving in hours is around 30 percent. The improvement in what those hours are spent on is larger and harder to quantify.
The biggest saving comes from agreeing the scope first
The largest saving has nothing to do with models.
The single biggest cost in conventional software delivery is rework caused by ambiguity. Someone builds what they understood. The result differs from what was meant. The difference is discovered late, when it is expensive, and the fix ripples through everything built on top of it.
A written scope with an explicit definition of done, agreed before anyone writes code, removes most of that. This approach is available to any firm that wants it. Most do not want it, because ambiguity is commercially convenient when you bill by the hour.
We put a number on it reluctantly, because it varies enormously by client. On projects where the scope was genuinely nailed down first, rework fell by more than half.
Some work still takes the same human time
This is the part that gets left out of every vendor pitch. It is why the claim is five times rather than fifty.
Some parts of a project do not compress.
- Understanding your business. Nothing accelerates the conversation where someone explains why the exception exists and which customer it was for. That is human time and it is irreducible.
- Decisions with consequences. Architecture choices that will be lived with for a decade need somebody accountable. A model can lay out the options faster. It cannot carry the decision.
- Integration with things that are not yours. Third-party APIs behave how they behave. Their rate limits, their outages and their undocumented quirks consume exactly as much time as they always did.
- Security review and compliance. Slightly worse than before, if anything. There are new questions to answer about data boundaries and model providers, and the people asking them are appropriately cautious.
- Testing against reality. A model can write tests. It cannot tell you that the real supplier feed sends dates in three formats depending on the day of the week. Only production tells you that.
- Waiting for people. Access, approvals, credentials, a decision from someone on holiday. On many projects this is the true critical path and no technology touches it.
The hour saving alone does not get you to five times
Take a project that was conventionally 1000 hours, split by the percentages above.
Discovery 150 hours becomes about 45. Implementation 400 becomes about 240. Review and rework 250 becomes about 175 from the review saving, then falls further as scope discipline removes rework, call it 120. Deployment and documentation 100 stays roughly 90. Project management 100 falls to perhaps 70, because there is less to coordinate.
That totals around 565 hours against 1000. That is a bit under twice as fast, rather than five times.
Five comes from two places. First, elapsed time compresses faster than hours, because a smaller team with less coordination overhead runs more of the work in parallel and waits less. Second, the comparison is against what the market charges, which includes a sales function, an account management layer and a margin structure built for a different cost base.
We are explicit about this in every proposal. The comparison figure is what conventional delivery would cost you, and we state it beside our number so you can check the arithmetic yourself.
We pass the saving on because the margin advantage will not last
A firm whose costs drop by half has a choice. It can keep the margin and enjoy an unusually good few years, or pass it to clients and compete on price.
Most of the industry chose the first. That is a rational choice and it is available for as long as buyers cannot tell the difference.
We chose the second, for a reason that is more commercial than principled. The margin advantage is temporary. Competitors will reprice eventually. The durable asset is a decade of delivered work, published client reviews and a reputation for saying no to projects we cannot beat the market on. Volume today buys that. Margin today does not.
It also means our incentives point the right way. A firm billing by the hour is punished for getting faster. We are not, so we can adopt anything that works without arguing with our own revenue model. The full commercial structure is on the engagement models page.
We measured this against our own estimates and actuals
A claim like ours is worthless unless we say where the numbers came from. The method matters, and so do its weaknesses.
We have delivered fixed-scope work for long enough to have a reasonable history of estimates against actuals. Since we price fixed, our estimates have always been recorded carefully, because being wrong costs us directly. That gives a baseline that most agencies do not have, because a time-and-materials firm never has to reconcile an estimate to anything.
For the AI-assisted figures, we compared similar work before and after. We controlled for team seniority and domain familiarity where we could.
Similar is doing a lot of work in that sentence. No two projects are the same. Our people got better over the same period for reasons unrelated to tooling. The sample is tens of projects rather than hundreds.
So treat the phase percentages as our honest reading of our own data rather than as research. They are directionally right and precisely wrong. Anyone quoting this kind of figure to two decimal places is making it up.
The first failure mode is building more because building is cheaper
There is a specific way this goes wrong, and we have done it, so we should name it.
When implementation gets cheap, the temptation is to build more. Scope that would previously have been cut because it was not worth 40 hours now looks affordable at 20. Multiply that across a project and you have spent the entire saving on features nobody asked for, while telling yourself you were being efficient.
The discipline that prevents it is the same written scope that produced the largest saving in the first place. If it is not in the scope, cheapness is not a reason to build it. We review this specifically at the midpoint of every engagement, because the drift is gradual and feels like generosity at the time.
The second failure mode is skipping the specification
The second failure mode is subtler. Faster implementation tempts teams to skip the specification, on the theory that building is now cheap enough to be exploratory.
That reverses the largest saving on the list in exchange for the smallest one. It is how a project that should have taken six weeks takes five months of enthusiastic iteration.
We decline work when the saving is not real
The claim comes with a corollary we take seriously. If we cannot beat conventional delivery meaningfully on a piece of work, we say so and decline it.
That happens in three situations.
- When a standard product already fits, and the honest advice is to buy it and configure it.
- When the work is mostly integration with a system whose constraints dominate everything else, so there is nothing to accelerate.
- When the client’s own decision-making is the bottleneck, in which case a faster supplier changes nothing and we would be selling a saving that cannot be realised.
We have lost work to all three. It is the least popular part of the model internally and the part that makes the number credible externally.
Ask suppliers where the saving actually comes from
If a supplier tells you AI has made them dramatically cheaper, four questions separate a real position from a marketing one.
- Which phases got cheaper, and by how much each? A single blended figure is a sign nobody measured.
- What did not get cheaper? An honest answer has several items in it.
- Are you passing the saving on, or keeping it? Both are legitimate. The answer tells you what you are buying.
- What would make you decline a project? A firm that declines nothing is optimising for something other than your outcome.
If you have a piece of work and want the arithmetic done against it specifically, send us the shape of it. You will get a written approach with both numbers in it, including the conventional one.
