Controlled Document Register & Version Control
Hold every SOP, policy, and form in one register — document number, title, owner, current version, effective date, status, and the actual file — so there is exactly one official current version of each document. A new version becomes 'current' only after the document controller approves the bump, which automatically supersedes (but never deletes) the prior version.
A web tool where you import your existing document list, upload the file for each document, and then control versions properly: when someone proposes a new version, the document controller reviews and approves the version bump, which automatically marks the prior version 'superseded' (kept, not deleted) and makes the new one the single 'current' version. The register enforces one current version per document number, keeps the full version history with effective dates and who approved each, emails owners when their document changes, and exports the register as CSV in your exact columns.
Before you start
- A Supabase account (free)
- A Vercel account (free)
- A Resend account (free)
- Your current document list (number, title, owner, version, date) as a CSV or Google Sheet
- The document files themselves (PDF / Word) to upload
- Claude Code or any AI coding agent
The problem this kills
Open the shared drive and count the copies. SOP-014 final.docx, SOP-014 final v2.docx, SOP-014 FINAL final (use this one).docx. Somewhere in there is the version people are actually supposed to follow — but nobody is completely sure which one, and the person who renamed it last week is on vacation.
That is the document-control nightmare: not that documents go missing, but that there are too many of them, and no single answer to the only question that matters — what is the one current, official version of this document right now, and when did it become effective? An auditor asks to see the controlled copy of a procedure. An operator pulls up whichever file came up first in search. A new version gets saved straight over the old one, and the history — what changed, who approved it, when it took effect — is gone forever.
Folders cannot enforce "one current version." A spreadsheet of version numbers drifts out of sync with the actual files the moment someone is in a hurry. This is exactly the kind of rules-based, must-be-auditable control that a small internal tool does better — and you do not need to be a developer to build it.
What you'll build
A simple internal web tool for your quality / document-control team: a controlled document register. Each document has a number, a title, an owner, a status, an effective date, a current version — and the actual file attached. The register guarantees exactly one current version per document number, with the full history of every prior version kept alongside it.
The heart of it is the version bump. When a document needs updating, someone uploads the new file and proposes a new version. It does not go live on its own. The document controller reviews and approves the bump — and only then does the tool make the new version "current" and automatically mark the previous version "superseded." The old version is never overwritten and never deleted: it stays in the history with its old effective date, so you can always show exactly what was in force on any date. Resend emails the owner (and whoever you choose) when their document changes, and you can export the whole register as CSV in your exact columns.
What's inside the Implementation Plan
The plan is a single file you paste into an AI coding agent. It opens by interviewing you about your business — your document-number scheme (the prefixes and ranges you use, like SOP-, POL-, FRM-), how you write version numbers, what your statuses are called, who is allowed to approve a version bump, how you set effective dates, and your messy edge cases — and then tailors the register columns, the validations, and every later step to your answers. This is a register shaped around how you control documents, not a generic template.
From there it walks the agent through the database schema, importing your existing document list, uploading a file per document, the controller's approve-the-version-bump gate (the one that supersedes the prior version), keeping the full version history with effective dates, Resend notices to owners, and the CSV export. Every step ends with a ready-to-copy prompt. Because the whole thing runs on a CSV / Google Sheet import and files you upload — and produces a clean CSV export in the columns your system expects — you can build and use it this weekend even with no connection to any existing system.
The governance it includes (this is the point)
This is the system of record for your controlled documents, so it is built like it matters: login so only your team can use it, row-level security so you only ever see your own organization's documents, and a complete audit trail of every import, upload, proposed version, approval, supersession, and export — who did what, and when. Nothing goes "current" automatically: a new version is a draft proposal until the document controller approves the bump, and that approval is the hard human-in-the-loop gate — there is no silent overwrite. The moment a bump is approved, the prior version is automatically marked superseded and kept, not deleted, so the history is intact. Duplicate guards keyed on document number + version mean the same version of the same document can't be created or approved twice, and a database rule enforces exactly one current version per document number.
Who it's for
Document controllers, quality managers, and operations leads in any organization that has to keep controlled SOPs, policies, work instructions, and forms — manufacturing, medical devices, food, labs, healthcare, services under ISO or similar. If you can describe your document numbers, your version scheme, and who is allowed to approve a change, you can build this.
You've got this — open the plan, paste the first prompt, and let it interview you about how you control documents.