It is almost never the code
Across 153 reviewed projects the pattern is consistent: when a project goes wrong, the code was usually adequate and the agreement was not. Nobody sets out to build the wrong thing. What happens is that the thing nobody wrote down gets built anyway, and discovered halfway through.
The four traps
1. The unwritten “obvious” requirement
One side assumes responsive, the other assumes desktop. One assumes content will be supplied, the other assumes we will write it. Neither says so, so it is discovered at the handover stage, when changing it is expensive. Write down what feels obvious; that is exactly what is not obvious.
2. The content trap
The site is built and beautiful, and there is no text, no product photos and no pricing. This is the single most common cause of a stalled launch. Content is a work stream with an owner and a date, or the project is not finished.
3. The third-party dependency
A payment gateway, a courier API, a booking system, a font licence. It is not your code and it is not your vendor. When it behaves differently than expected, the project stops, and the first conversation should be “whose component is this?” — not “who is at fault?”
4. The change nobody priced
Somebody asks for one more thing mid-build. Absorbed silently, it becomes resentment; absorbed loudly, it becomes a dispute. Quoted separately, it is just a small invoice.
What actually prevents it
- One page that lists what is included and what is not.
- Decisions recorded in writing, with dates, before work starts.
- Named owner and deadline for content.
- Change-orders quoted before work begins — never absorbed quietly. Our fixed-price versus hourly piece covers why that protects both sides.
- A change log, so the record of what was agreed lives with the project.
This is not theory. It is the process behind our
Next step
If you already have a quote that feels vague, send it over. We will tell you what is
missing from it, at no charge:
What is the “obvious” requirement you would not bother writing down?