Project docs

Who can use it: firm staff write docs. Clients read every doc, drafts included, and comment.

Project docs describe the project as a whole: the problem, the users, the architecture, the rules. Every feature is written and built against them, and records which version of each doc it was based on.

Why it matters

Without shared background, every feature re-explains the basics, or worse, assumes different things. With signed-off docs, Arjun’s spec and Lena’s tests start from the same understanding Tom agreed to.

Use case

Ravi fills in Business Problem: “Weekly shoppers spend 15 minutes rebuilding the same basket.” Tom signs it off. Meera writes Architecture and Tech Stack and signs them off as Architect. Later Tom asks for a new persona, so Ravi edits Personas. A new draft starts, while features keep using the version Tom signed until Tom signs the new one.

The eight built-in docs

Business (signed off by the client)

Doc	Answers
Business Problem	The problem the project solves, and for whom
Current State	New build or existing product, and what’s already there
Product Description	Market, core capabilities, expected traffic and storage
Personas	The people who’ll use it
Success Metrics	The outcomes you expect, with targets

Technical (signed off by an Architect)

Doc	Answers
Architecture	Components, network and data flow
Tech Stack	Languages, frameworks, database and hosting
Conventions & Constraints	Rules the code must follow

Each doc starts with sections and a hint under each one explaining what to write.

Write, review, sign off

stateDiagram-v2
    [*] --> Empty
    Empty --> Draft: Save
    Draft --> InReview: Submit
    InReview --> SignedOff: Sign off
    InReview --> Draft: Request changes
    SignedOff --> Draft: Edit again
    state "In review" as InReview
    state "Signed off" as SignedOff

1. Edit the doc and save. Every save is kept as a version.
2. Submit it for review.
3. The right person signs it off, or requests changes:
   • a client user for Business docs;
   • an Architect for Technical docs.

Editing a signed-off doc starts a new draft. Until that draft is signed off, features keep using the last signed-off version.

Docs gate features

A feature’s requirement can’t be signed off until all five Business docs are signed off. A spec can’t be approved until Architecture is signed off.

Custom docs

Need something the eight don’t cover, such as Payment Provider Notes? Firm staff can add a custom doc:

• Pick a title and a group, Business or Technical. The group decides who signs it off.
• It has the same versions, review, sign-off and comments as the built-in docs.
• It doesn’t block features.
• You can archive and restore it, and organise it in folders.

Files

Anyone on the project, clients included, can upload reference files under Docs → Files: PDF, Word, Excel, PowerPoint, images, text, Markdown or CSV.

Tom uploads Harbor’s brand guidelines PDF and last year’s order data as a spreadsheet.

Only project members can open the files. The uploader, a Project Manager or a Super Admin can edit a file’s note or delete it.

Export

Export the docs as one Markdown file, for example to give a coding assistant the full background. You can also export a single folder.