Technical Specification & PRD — the document a developer can quote against

A technical specification document is what makes two quotes comparable

Without a written scope, a vendor quotes what they imagine. The gap between what they imagined and what you meant gets settled later, as a change request, at your expense. That is not dishonesty — it is what happens when the brief is a conversation.

A technical specification document, or PRD, is what lets you put three vendors against the same brief and read the difference between the quotes as information rather than noise.

What you get

Functional requirements, ranked

Every requirement classified must-have, should-have, or later. The ranking is the part vendors quote against, and the part that survives the first budget conversation.

The data model

Entities, relationships and the fields that matter, written before anybody opens an editor. Most expensive late changes in a software project are data-model changes wearing a feature's clothing.

Acceptance criteria, written before the build

What "done" means for each requirement, in terms you can test without a developer present. Written afterwards, acceptance criteria describe whatever was built. Written first, they are a contract.

A build and budget estimate

A range with the assumptions attached, so you can tell whether a vendor's quote is aggressive, padded, or quoting a different product.

A tender-ready package

The whole thing in one document you can send out as-is. No appendices you have to assemble yourself.

How the ten days run

Days 1 to 2 — scoping interview

Two hours, recorded. What the product must do, for whom, and what would make it a failure.

Days 3 to 6 — the draft

Requirements, data model and acceptance criteria, written and sent to you as a draft rather than as a finished artefact.

Days 7 to 8 — your review

One review round, on the document, with your comments in it.

Days 9 to 10 — the final document and the estimate

The second review round and the build estimate. Two rounds, stated up front, is the whole revision budget.

A worked example

A non-technical founder had two quotes for the same mobile app: $18,000 and $47,000. The specification took eight days and showed the cheaper vendor had scoped no offline mode, no role management and no admin back-office — about 60% of the product by effort. The expensive quote was not expensive; the cheap one was quoting something else. The document cost $700 and turned an unreadable decision into an obvious one.

Who this is not for

• Anyone who needs the product built — I write the specification, I do not bid on the build
• A team that already has a written scope and wants it reviewed (that is the Delivery Risk Audit)
• Anyone who wants a fifty-page document as an artefact; the deliverable is as long as the product requires and no longer

What is not included

I do not build it, I do not manage the build, and I do not run the tender on your behalf. Revisions are capped at two rounds, stated up front, because an uncapped revision loop is how a fixed price stops being fixed.