Why your last project ran over
Projects overrun because scope was discovered rather than decided, decisions waited on someone, integrations behaved differently than documented, and nobody defined what finished meant. Coding speed is almost never the cause.
When a build takes twice as long as expected, the instinct is that the estimate was wrong or the developers were slow. Occasionally true. Far more often the time went somewhere else entirely, and it went to the same four places it always goes.
Scope was discovered, not decided
Nobody sets out to expand the work. It expands because building forces questions that thinking never did.
You asked for a customer list. Building it surfaces: what about customers with two addresses? Do we keep the ones who left? Who can see the phone numbers? Each is a legitimate question and each has a cost, and none of them were in the original request because you had no reason to think of them.
What helps: build the smallest version first and use it. Real use generates those questions in days rather than dribbling them out over months. It does not eliminate the discovery. It front-loads it, while changing your mind is still cheap.
Decisions waited on someone
This is the biggest one, and it is almost never in anybody’s post-mortem.
A build stops when it hits a question only you can answer. If that question is asked on Tuesday and answered the following Monday, you have lost most of a week on something that took thirty seconds to decide. Do that six times and the project is a month late without a single line of code being slow.
What helps: agree upfront who decides and how fast. One person with authority and a one-working-day turnaround is worth more to a schedule than an extra developer.
An integration behaved differently to its documentation
Anything connecting to another system carries this risk. The API is undocumented in the part you need, or documented wrongly, or rate-limited in a way nobody mentioned, or the sandbox behaves unlike production.
This is the one genuinely hard to plan around. It is also why an experienced builder will hedge specifically on integration work while being confident about everything else: not evasion, just knowledge of where the landmines are.
What helps: do the integration first, not last. If it is going to be horrible, find out in week one while there is still room to change approach.
Nobody defined finished
If “done” was never written down, the project cannot end. It just gradually becomes less active, with a tail of small requests that each feel too minor to argue about.
What helps: one checkable condition per piece of work, agreed before it starts. Not “improved reporting”: “she can see last week’s overruns in under ten minutes without exporting anything.” You can hold that up against the result and get an answer.
What this means for how you buy
Three of the four are about how the work is organised rather than how fast anyone types. Which is why fixed-price projects overrun so reliably: the model assumes scope is knowable upfront, and then the discovery problem does what it always does, except now it arrives as a change order and an argument.
Continuous arrangements handle it better, not because anyone is faster, but because nothing has to be renegotiated when the work turns out to be different from the description. You reorder the queue and carry on.
None of which excuses genuinely bad estimates. But if your last project ran over, it is worth asking where the time actually went before concluding you hired the wrong people.