Software projects go wrong in predictable ways. The most common: the client thought they were buying X, the agency thought they were building Y, and neither side discovered the mismatch until month three. By then, the budget is gone and the relationship is strained.
Interactive · The Mismatch Timeline
How a project goes wrong without a spec. Click each month to see what's actually happening on both sides.
Click a month to see what's actually happening on both sides of the project.
The fix isn't better communication during the build. It's a better contract before it. At SMS Group, every project starts with a specification document — not a scope of work, not a feature list, but a document that defines, for each module, what done looks like. We call these acceptance criteria. They're written in plain language, agreed before a line of code is written, and signed by both parties.
Interactive · Spec Contrast
Compare what a vague brief looks like vs acceptance criteria written for a fixed-price contract.
Vague — opens every dispute
"The dashboard should show all the important information and look professional."
What does "important" mean? What does "professional" mean? Who decides when this is done? No one knows — including the agency.
Fixed-price contracts only work when the scope is fixed. Most agencies avoid them because they're afraid of being held to a spec they didn't write carefully enough.
Acceptance criteria change the dynamic of the relationship. When a client says 'I thought this would also include X,' we can open the spec together and ask: is X in here? If it's not, we discuss whether it's worth adding. There's no ambiguity, no blame, no bad faith — just a written record of what was agreed.
Fixed-price contracts only work when the scope is fixed. Most agencies avoid fixed-price because they're afraid of being held to a spec they didn't write carefully enough. We lean into it, because it forces us to think harder upfront — which produces better software and better client relationships.
The spec is also how we protect you. If a junior developer joins the team, or we revisit a module six months later, the spec tells everyone what the system was supposed to do. It's not just a contract — it's the institutional memory of the project.