Creative
Content approval for a marketing agency
An agency drafts content for several clients. Each piece moves from draft to internal review to client approval, with comments at each stage. A client sees only their own content, and an approved piece is locked from further editing.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
An agency drafting content for multiple clients must seamlessly transition pieces through internal review and client approval while strictly enforcing row-level client segregation and write-locks on approval.
Section 03 · Screens
Every screen, and what it is for.
- ›Dashboard — Agency user views all active drafts and bottlenecks; loading the active piece list must be instant.
- ›Drafting Workspace — Agency writer edits content and tags collaborators; text autosave feedback must be instant.
- ›Internal Review — Agency manager reviews draft and posts internal notes; rendering comment threads must be instant.
- ›Client Portal — Client reviews pending pieces and approves content; submitting an approval decision must be instant.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
client
id uuid, name text, created_at timestamptz
Access · Agency users read all; clients read only their assigned organization record.
content_piece
id uuid, client_id uuid, title text, body text, status enum(draft, internal_review, client_approval, approved, locked), created_at timestamptz, updated_at timestamptz
Access · Agency reads all; clients read rows where client_id matches their tenant.
comment
id uuid, content_piece_id uuid, author_id uuid, audience enum(internal, client), body text, created_at timestamptz
Access · Agency reads all comments; clients read only comments where audience is client.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
draft → internal_review → client_approval → approved | locked
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
Clients posting internal-only comments directly onto content pieces via manipulated API payloads.
Enforce audience visibility constraints at the database level using row-level security policies tied to user roles.
Concurrent edits by multiple agency writers corrupting content body text right before review submission.
Implement optimistic locking via an updated_at timestamptz check on every content write operation.
Section 08 · Deliberately left out
What version one does not do.
- ×Rich media inline image uploads in the draft editor — adds heavy S3 dependency, defer to v2 when visual layouts are requested.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- Should clients be permitted to invite multiple colleagues to their portal, or is each client restricted to a single login?
- When a piece is rejected by a client, does it loop back to internal review or directly to draft status?
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.