Requirements, versioned

Show them the record, not your recollection.

Every requirement carries its own history — branches, splits, merges, and the moment your customer approved it. Open the timeline and the argument is over.

R-014 — Bulk export of approved scope
v1 draftedbranch: csv-or-pdfmergedoption Achosenv4 approved

Two options were priced. One was chosen on 14 May. Both are still in the record.

The approval loop

One meeting, many edits, one email

A workshop produces twenty changes, not twenty approvals. Batch them, send one link, and let your customer work through it in their own time.

  1. 01Capture scope as structured requirements, on a branch
  2. 02Group what changed since the last sign-off into a batch
  3. 03Send one link — no account for them to create
  4. 04Decisions land per item, with reasons, in writing

Approval batch 07 — Northgate portal

6 changes for review · sent 14 May

  • R-014 · Bulk export of approved scopeApproved
  • R-021 · Single sign-on for staff usersApproved
  • R-022 · Offline mode for site engineersRejected
  • R-023 · Weekly digest to the client sponsorAwaiting

R-022 rejected — “budget sits with the field team, not us.” Reverted to v2; the attempt stays in history.


What it does

Structured requirements, and everything that happened to them

Structured requirements

Templates, acceptance criteria, priority, tags. The same shape on every project, so nobody invents a format mid-engagement.

Branch-aware versioning

Branch when options diverge, split when one requirement is really three, merge when a direction is chosen. Nothing overwritten.

Approval batches

A portal your customer can read without an account, and a decision recorded per item rather than per email.

Audit trail

Append-only. Actor, timestamp, before, after, and why. Rejected changes stay visible after the revert.

Basecamp and GitHub

Map requirements to card tables and pull requests, so the record reaches the places the work actually happens.

A document to send

Generate a readable scope document straight from the live record, instead of rewriting one by hand before every meeting.


Who it is for

Anyone who has to say what was agreed, and when it changed

All of them on one delivery team, with a customer on the other side of the requirement. If there is not, you want a requirements tracker, and there are good ones.

You own the backlog, and you are the one asked why something changed.

Every edit is versioned and every approval is dated, so the answer is a link rather than a search through email. Priorities and tags stay yours to move without asking anyone — re-prioritising is a delivery decision, not a customer one.

Most used

The branch timeline, and the document view you send before a steering meeting.


Beta

We are in beta. Join the waiting list.

We are letting teams in a few at a time so we can set each one up properly. Leave your details and we will be in touch when there is a place.

Join the waiting list