Nothing here is a criticism of systems integrators. Good ones do difficult work well. The argument on this page is about what they are given to work with.
AUG 12 2026
“What if I just hired a systems integrator?”
It is the right question, and it deserves a real answer rather than a slide. So we ran it against a system we actually built, using the estimate written before the first commit.
Step one — what you get quoted
The system: 11 features, 106 use cases, 765 planned tasks. Estimated the standard way — story points, times hours per point.
2,892 story points × 4 hours = 11,568 development hours
≈ 72 team-weeks. About seventeen months.
≈ 72 team-weeks. About seventeen months.
That is a competent estimate. It is also the number the proposal is built on — and it is not the number you will spend.
Step two — four things that estimate does not cover
Discovery
Read the line items: setup, design, use cases, integration, QA, final tasks. There is no discovery. The estimate begins after good requirements exist. Producing them — workshops, interviews, process mapping, the written spec, review cycles, sign-off — is its own project, staffed by your most senior people.
Rewrites
A requirement that reads two ways gets built one way. Then it gets specified again. That second pass is analyst time nobody quoted, and it happens before anyone calls it a defect.
The standing meeting
Where delivery happens at distance, requirements are written in one place and built in another. That needs a review rhythm: twice a day at the start, once a day from the third sprint, for the life of the build. Over seventeen months it is hundreds of senior hours whose only output is agreement.
Change orders
The part everyone expects and nobody budgets. On a fixed-scope custom build these are not an overrun — they are the mechanism by which an ambiguous specification becomes a working system.
Notice that the review rhythm thins out as the build goes on — twice a day early, once a day later. That is not a scheduling convenience. Ambiguity is highest before anything is built, and those meetings exist to resolve it. The cadence is a readout of how unclear the requirements were.
Our assumptions, before the totals
Two of the numbers below are measured and two are assumed. We would rather you know which is which than be persuaded by a total you cannot take apart.
- MEASURED
- 11,568 build hours — from the project’s own estimate file, written before the first commit.
- MEASURED
- 433 hours and 38 hours — logged actuals and commit timestamps from two separate repositories.
- ASSUMED
- Discovery, rewrites and coordination: 1,722 hours combined. Discovery at 5% of the build estimate, one analyst’s rewrite pass, and the review rhythm described above at 45 minutes a session for one onshore lead plus two attendees. Change these and the totals change.
- ASSUMED
- Change orders at 20%, 40% or 60%. We do not publish a single figure because we cannot source one. You know your own overrun history better than we do. Pick the column that matches it.
Step three — assemble it
| Discovery, rewrites, coordination | 1,722 h |
| The build you were quoted | 11,568 h |
| Change orders — 20% / 40% / 60% | 2,314 / 4,627 / 6,941 h |
| What it actually takes | 15,604 — 20,231 h |
You were quoted 11,568. The work is 15,600 to 20,200.
The proposal covers somewhere between 57% and 74% of the effort. Nobody is being dishonest. The estimate is simply answering a narrower question than the one you asked.
Step four — put your own rate on it
We are not going to tell you what your delivery partner charges. Two bands cover most of the market. Use whichever describes your situation, or use your real number.
| Blended rate | At 20% change orders | At 60% change orders |
|---|---|---|
| $45/hroffshore-enabled blend | $702,180 | $910,395 |
| $125/hronshore | $1,950,500 | $2,528,875 |
Rate bands are illustrative market ranges, not any firm’s rate card. The hours are the argument; the rate is yours.
Step five — what actually happened
We built this system twice, from one Alchemist requirements package, with two teams who never touched each other’s code.
Requirements — both builds → under 12 hours, once, no standing meeting
Five senior engineers, none had used the tool before → 433 hours to production
One person with no development background → 38 hours to a working application, 21 days
Five senior engineers, none had used the tool before → 433 hours to production
One person with no development background → 38 hours to a working application, 21 days
Against an estimate of 11,568 hours, and a realistic total nearer 15,600 to 20,200. Same scope. Same use cases. The requirements were the only thing that changed.
This is not a new finding. It is the best-measured fact in software delivery, and the industry has published it repeatedly. From the Consortium for Information & Software Quality’s 2022 report:
“The cost of finding and fixing deficiencies is the largest single expense element in the software development lifecycle. Over a 25-year life expectancy of a large software system, almost fifty cents out of every dollar will go to finding and fixing bugs.”
“The earlier in the development lifecycle deficiencies are found, the more economical the overall delivery will be.”
Half the money goes to finding and fixing. The earlier you find, the less you spend. Requirements are the earliest place there is.
What we are not claiming
That systems integrators are the problem. They are not. Hand a good integrator a precise, traceable specification and they will deliver against it — faster and cheaper than the numbers on this page, because most of what inflates those numbers is ambiguity, not capability. The argument is about the input.
That the estimate was wrong. It was computed correctly from the package in front of it. The question is what that package was worth before anyone multiplied it by four.
That our two builds finished in the same place. The 38-hour build reached about 85% of scope and stopped where we chose to stop it. The 433-hour build went to production and runs the business today. Finishing the first would take more hours, and we would rather say so than compare a demonstration to a product.
That your programme will match ours. This is one system, built twice, with the records published. It is evidence, not a guarantee — and one honest result is worth more than a range we cannot support.
If you are holding a proposal right now, the useful exercise takes an afternoon: ask what it assumes about requirements quality, and ask what happens to the number if that assumption is wrong.
Bring us the scope and we will run the requirements against it — jamie@acc3int.com
Alchemist AI Pro™ is free to use — alchemistaipro.com
Measured figures come from the project’s git history, contributor time logs, and the estimate written before the first commit. Discovery, rewrite, coordination and change-order figures are modelled and labelled as such above. No delivery partner is named, and no firm’s rate card is reproduced.