For engineering & product teams

Make sure engineers build from the approved spec.

Specs change mid-sprint. VersoDocs routes each change through engineering review and product approval, and shows exactly what changed between v12 and v13.

Start freeSee the workflow
The problem

The spec people build from is rarely the one that was agreed.

A requirement gets tweaked in a comment, a thread, a meeting. Half the team hears about it. The other half ships last week’s version.

Silent edits

Someone edits the live spec. Nobody reviewed it, and engineers who already read it never find out.

Decisions in side channels

The spec says one thing, the ticket another, the code a third.

“Which one is current?”

spec-v3-final, spec-v3-final-2, a Notion copy. Each task starts with working out which to trust.

How it works

From v12 to v13, without anyone building from the wrong one.

Engineers keep reading the approved version until the next one is published.

  1. v12 · CURRENT

    Engineers build from v12.

    The Checkout API spec v12 is Current: the version engineers see, protected from direct edits.

  2. PROPOSAL

    PM proposes a change.

    Product wants idempotency keys on retries. The PM drafts it in a private proposal. v12 stays as is.

  3. REVIEW

    Engineers review the diff.

    The tech lead comments on the exact line and requests changes. The next revision shows only the delta.

  4. APPROVAL

    Product approves.

    With engineering sign-off in, the product owner approves. Nothing goes live without it.

  5. v13 · CURRENT

    v13 is published.

    v13 becomes Current with its reviewers and reason attached. v12 is kept, locked and dated.

The math

One wrong requirement costs more than a year of seats.

20 h
engineering time lost to one obsolete requirement
~$2,000
at a $100/h loaded engineering cost
$100 / mo
VersoDocs Team for a 10-person team (annual)

Two engineers spending a week on an obsolete requirement is easily 20+ hours, before rework. Team is $10 per seat per month. Illustrative numbers; yours will vary.

Why spec teams use it

Built for documents that code depends on.

The editor stays familiar, and nobody needs git. What changes is that every version is agreed before anyone builds from it.

One Current version

Every spec has exactly one Current version. Links, readers and exports always land on it.

Review the change, not the doc

Reviewers read a diff, not 14 pages. Each revision shows only what moved since their last review.

“Why did we do this?” answered

Every version carries its proposal, review and approver. Overrides are logged too.

Specs in the repo and in CI

npx @versodocs/cli pull writes the approved spec into the repo with a lockfile, on every plan. On Team, a GitHub check fails PRs built from an outdated spec.

Agents read the approved spec

Claude Code, Cursor or Copilot connect over MCP and get the Current version, never a draft. Details on the developers page.

The team hears about v13

Every new version posts to Slack or Teams with who approved it and a link to the diff. On Team, reviewers approve from Slack.

Questions

Good to know.

Do engineers have to learn a new tool?
Reading is just reading: the Current version opens like any doc. Reviewing is a diff with comments and Approve / Request changes, which engineers know from code review.
Can we keep writing in Google Docs or Notion?
Yes. Many teams brainstorm there and import a spec into VersoDocs once people build from it. Import works on every plan, and the spec can go live as v1 right away.
What if a change is urgent?
Admins can override the approval rule and publish immediately. The override is recorded on the version.
Can people outside our org review a spec?
Yes, on Team and Pro. Invite a client, legal or QA by email. They review the diff without an account and never use a seat.
How does the team find out about v13?
In-app, by email and in Slack or Microsoft Teams on every plan. Team and Pro add digests, every event in chat, JSON webhooks and an AI summary of what changed.
Can our AI coding agents use the spec?
Yes. Connect Claude Code, Cursor, Copilot or Claude Desktop over MCP, then ask “pull the approved Checkout spec and implement section 3”. Agents only see published versions. On Team they can also open proposals (25 a month; unlimited on Pro), but never publish.
Keep reading

More on VersoDocs.

SOPs & procedures →

Controlled SOPs with approval before publish, proof of which version was in force, and read-and-acknowledge.

Developers & AI agents →

A remote MCP server, a CLI with a lockfile, GitHub auto-sync and a REST API that only ever return the approved version.

VersoDocs vs Google Docs →

Real-time co-writing vs one approved version: when to use each, and how teams use both.

VersoDocs vs Notion →

A flexible workspace vs controlled publishing for the documents that need one approved version.

VersoDocs vs Confluence →

A team wiki with approval add-ons vs approval built into the only way a document changes.

Bring your most-changed spec.

Free for two people. Run one change through a proposal and see the difference by v2.

Start freeSee pricing