Specroot Waitlist open

For agencies and consultancies

Client sign-off that stays true after the next change.

Your spec, versioned. What the client signed off stays readable, unchanged, at its own address. Every change request shows what it touches — requirements, work items, the work already built on them — before anyone agrees to it. And nothing merges until the client signs off on the change too.

they signed off. we built. Last week they came back and said it doesn’t feel right and they want to go in a different direction. … Redoing probably 60% of the work. not getting paid for it.

— r/webdev, March 2026

Client sign-off

Your client reads the document, not your tools.

One address lands them on the document, with what changed marked and the state beside it. They comment; you are emailed. They sign off or decline, and the decision is recorded with who and when. Nothing merges until they do.

Review · Payments, business level frozen 18 Aug
§ 2  A refund is issued against the original payment only.
+ § 2.1 A partial refund is allowed once, and never after 90 days.
§ 3  A failed payment is retried twice, then abandoned.
Maria (client): Ninety days is wrong for corporate accounts — those settle on 120.
Author emailed · correcting session started from this comment
automatic
Approve Decline Merge — blocked until approved
Baseline 12 AugApproved by Maria · 12 Aug
stale · basis moved

Our own specification, in the product

Change impact

A change shows what it touches before anyone says yes.

When the client asks for something new, the change is worked on where the signed-off version cannot see it. Every requirement and work item it touches is marked, so the conversation about cost and dates happens before the work — not on the invoice.

Decision applied · what it touches 11 records marked
FR-022Closing a session freezes its baseline
revisit
FR-032The author opens a review on the latest baseline
revisit
FR-033Nothing freezes while anything is unsettled
unaffected
AC-207A frozen baseline names one version of every record
revisit

Work item built from these

TASK-027Close and freeze
basis moved
pinned to FR-022 v2 · FR-032 v1 · FR-033 v1

Our own specification, in the product

Version history with reasons

What they approved stays readable.

Nothing is edited: every change is a new version under the same name, pointing at the decision that caused it — with the reasoning and who confirmed it. Six months later, the address you sent still shows exactly what they approved.

ADR-039 · decision accepted
v1→v2→ v3 · current confirmed 17 Aug
Context
Six months after approving, a client opens the address they were sent. Some records in it have moved on. It either shows what they approved, or what is true now — and those answer different questions.
Decision
What a client approved stays readable, unchanged, permanently — at the approved baseline's own address, which never reads current state.
Not chosen
Show current content with a note that the approval is out of date — it shows a client content they never agreed to.
Not chosen
Show current content with the differences marked — the best answer to both questions, and it needs a comparison the first release does not build.

Our own specification, in the product

Always-current documents

One document for the client, one for the team, and they agree.

The client reads the business level; the team reads the functional detail. Both are reads of the same records, drawn when they are opened, so there is no second copy to fall out of date.

Functional specification · live 73 records
§ 1Repositories and analysis
7 records
§ 2The session and the interview
14 records
§ 3Review, approval and merge
18 records
§ 4Transcript import
not captured yet
§ 5Cost and metering
out of date · last good read 14:02

Our own specification, in the product

Questions

“Will my client have to learn a new tool?”

No. One email invitation, one sign-in, then a single address that lands them on the document with what changed marked. They comment, sign off or decline — that is all there is. No anonymous links, on purpose: a sign-off is worth something only when it is provable who gave it.

“What happens when the client wants a change after sign-off?”

It is worked on in a change set the signed-off version cannot see. Every requirement and work item it touches is marked, and it cannot merge until your client signs off on it too. What they signed off before stays readable, unchanged, at its own address.

“We already use contracts and e-signature.”

Keep them — they settle what you are paid for. They do not say which version of the requirements a signature covers, or what a later change touches. That is the record kept here: the version, the decision, who gave it and when.

Read more

What Specroot is