Home › Blog › Spec quality and cost

How specification quality changes what development costs

Writing a more detailed specification does not always make things cheaper. There is detail that reduces cost, and detail that only adds it.

Detail that saves Over-specification Drawing the line

The short answer

A thin specification makes vendors price the uncertainty as contingency. So thin specifications are usually expensive.

But the opposite fails too. Specify the implementation and the vendor cannot use a better approach even when they know one — and when the result built to spec is not the result you wanted, the accountability is yours. Some things belong in detail; others belong left open.

Detail that reduces cost

Shape and volume of the data — Row counts, formats, where it lives. Uncertainty here attracts the largest contingency in a quote.

Permissions and roles — Who can do what. Change the permission model later and most screens need reworking.

Exception rules — What happens on a missing value, a duplicate, a failure. Unspecified exceptions always come back as questions mid-build.

Definition of done — What state ends the work. The cheapest sentence you can write for avoiding acceptance disputes.

Explicit exclusions — What is not in this phase. Without it you sign with mismatched expectations.

Integration targets and method — Which systems, and whether they have APIs. This is the single largest source of quote variance.

Detail that only adds cost

Over-specification	Why it hurts	Write this instead
Naming the technology stack	Stops the vendor using the stack they are strongest in	Express it as performance and maintenance requirements
Specifying database tables	Goes out of date the moment requirements move	List only the information that must be stored
Pixel-level screen instructions	Design review cost repeats endlessly	The information and actions each screen needs
Prescribing internal algorithms	Excludes better approaches	Inputs, expected outputs, accuracy threshold
Allocating the detailed schedule	Conflicts with the real order of work	Milestones and acceptance points only

One sentence that draws the line

The test is single: "if this is wrong, is the result unusable for our work?" If yes, specify it. "Is this a question of method?" If yes, leave it open.

For example, "exclude unapproved items from month-end settlement" is a business rule; get it wrong and the output is unusable. Specify it. "Run the settlement batch at 2am" is a method — the requirement is "complete before the next business day begins". Written the second way, the vendor can choose a safer arrangement.

Run a specification past this test once and it usually gets shorter and more accurate. What disappeared was the over-specification.

Specification precision also shapes the contract

Where the spec is settled, fixed price serves both sides. With clear scope the vendor has no reason to load in contingency.

Where requirements will emerge as you go, fixed price is risky: every change triggers a negotiation and the vendor prices heavy contingency up front. Phased delivery or a time-based engagement is often cheaper in total.

Either way, put the change process in the contract — request format, how impact is assessed, who approves. Without it, every mid-project change becomes a dispute.

Frequently asked questions

Can the vendor write the specification?

They can, but the business rules have to be settled by you. The realistic arrangement is that they draft and you review, with the review focused on whether the process is correctly reflected.

How long should it be?

There is no length target. If the six items above are present and there is no over-specification, it is the right length. A spec that is more than half screen description is usually over-specified.

What if requirements change mid-project?

Change is normal. What matters is whether a change process is in the contract. With one, change is a costing exercise; without one, it is a dispute.

Can we write the spec with AI?

It is well suited to structure and gap-checking — having it confirm all six items are filled in is particularly useful. Business rules and the definition of done must be settled by people.

Draft the spec

Start with the request document

The RFP generator drafts background, features, data and acceptance criteria — then you sharpen the boundaries without over-specifying.

Generate an RFP