Case study · Specifying and managing technical work
Most small businesses hire outside developers badly, and it is rarely because they picked the wrong person. It is because nobody wrote a brief that could be priced, nobody could tell whether what came back matched it, and there was no structured way to stop.
Most small businesses hire outside developers badly, and it is not because they pick the wrong people. It is because they cannot write a brief that a good person can price, cannot tell whether what came back is what they asked for, and have no structured way to stop if it is going wrong.
The engagements below ran across a large catalog rebuild and a site performance job, with a certified platform specialist working remotely on a fixed fee.
The specialist had previously completed a large job at a flat fee. When the next brief was drafted, the first estimate came in at nearly double that — on the reasoning that the new work was bigger.
It was not, and the client said so. The platform integration, the rate limiting, the checkpointing and the processing pipeline all already existed from the first job. The analytical work — the category structure and the data matching — had been done by the client and was being handed over complete.
“The prior job should not be the benchmark. It is something to build on, not replicate.” The brief was rebuilt at the original figure with a scope that reflected what was genuinely new. That is not haggling. It is scoping — and it only works if you can describe precisely which parts already exist.
Four milestones, four payments, four exit points
Each milestone was specified as an independently useful deliverable rather than a percentage of an eventual whole, and each was priced separately.
Week one was a data cleanup and one live test case — the smallest thing that proves the approach works end to end. If it fails, the client has spent $150 and learned something. Most fixed-price projects put the proof at the end, which is the one place it is no use to anybody.
The same structure made an uncomfortable conversation possible later. When the client’s cash position changed mid-project, he was able to say plainly that he could pay for the current milestone and could not commit to the ones after it. That conversation is only survivable if the milestones were independent to begin with.
A separate job asked the developer to fix a specific measured problem: images on the site were enormous and slowing it badly. He fixed it, and the fix was excellent.
What a before-and-after test actually caught
Both measurements taken with the same tool under identical simulated conditions, six days apart. The image payload result is unambiguous; so are the two regressions.
Resizing the images had stripped the attributes that reserve space on the page, so content jumped around as it loaded. The same pass had dropped the text descriptions that screen readers depend on. Neither was in the brief, in either direction.
A short memo: a seven-item punch list in priority order, starting with the change worth the most points; two direct questions the client could not answer from outside — what exactly shipped, and whether the descriptions were removed or had never been there; and one caution against quoting the headline improvement until the test had been run three times and the middle result taken. No blame, because there was none to assign. The brief had said what to improve and had not said what to preserve.
| The usual approach | What was done here |
|---|---|
| Describe the outcome you want | Describe the outcome, and what must not change |
| Price against the last invoice | Price against what genuinely remains to be built |
| Milestones as percentages of a whole | Milestones that each stand alone and could be the last |
| Accept the delivery | Re-measure under identical conditions before accepting |
| Complain, or say nothing | A priority-ordered punch list and two specific questions |
A brief that says what to improve and not what to protect will get you exactly what you asked for and something you did not want. Every specification needs both halves.
Marketing Analytics Consultants
We write the specification, structure the milestones so you can stop, and verify what comes back against what was asked — on the same instruments, before and after. We do not take a cut of the developer.