bizzbun — Blueprint v2.0 · validated delivery plan

What changed, and why

Two reviews — one a list of findings, one a full alternative blueprint — were checked against the repository. Most findings were confirmed, two were wrong, and one contradicted itself. This is the reconciled result.

01Shrink the build

The public website and lead inbox are removed. Task dependencies, sub-tasks, the stages tables and the reports module go with them. Twenty-four tables become eighteen.

02Fix the trust claim

"Round 1 preserved" was stored as a Drive URL. If the file behind it changes, the claim is false. Snapshots make preservation provable, or visible as drift.

03Client approval without an account

The 80%-active-portal target measured logins, not outcomes. An expiring, single-submission approval link becomes the primary path; accounts are optional.

04An honest schedule

v1.0 needed 38 days inside exactly 38 weekdays, full-time, with no contingency and no pilot month. This version budgets 48 days, a two-week break, a protected buffer and a 30-day pilot.

Validation register

Every material claim from the two revision documents, checked against this repository
Claim	Check	Verdict
Zero slack in v1.020 Oct – 10 Dec is exactly 38 weekdays and the phases sum to 38	Weekday walk = 38; 2+5+4+7+7+6+7 = 38	Confirmed
Phase 0 exit needs decisions dated after itRequires decisions 1–4; 1–2 were due 22 Oct, Phase 0 ended 21 Oct	index.html lines 1170, 1834, 1840	Confirmed
Immutable rounds stored links onlyNo revision ID, checksum or copy in submission_files	v1 schema: four reference fields, no snapshot	Confirmed
"A Drive URL is not authorization"Yet the plan relied on pasted Drive URLs	Gate 17 vs Phase 4 task list	Confirmed
Billing deferred but conversion promisedNo plan, subscription or entitlement table anywhere	v1 §13 vs "features to defer"	Confirmed
Trial and operator promises have no phaseExport, deletion job, impersonation logging	Phases 0–6 contain none of it	Confirmed
index.html links `css/styles.css`Document-hygiene finding from the first review	Line 14 links `styles.css`; no css/ directory exists	Rejected
Table count lands at 16–18Both reviews gave a range	24 − 7 dropped + 1 added = 18 exactly	Tightened
Build is 9–11 weeksThe listed phases sum to 8.5–10	48 working days ≈ 9.6 weeks	Recomputed
Stages table dropped, stage_id keptLeaves a foreign key pointing at nothing	Resolved: `stage` is a text label, logged in activity_log	Resolved

Assumptions that could not be settled in this environment are tracked with a verification date in section 11 — Google scope terms, DPDP dates, vendor pricing and real weekly hours.

Nothing from v1.0 disappears silently

Section ledger · v1.0 → v2.0
v1.0 section	v2.0 destination	Change
01 Scope	§02 Scope	Rewritten — website cut
02 Architecture	§03 Architecture	Extended — token path, snapshot, RLS
03 Roles	§04 Roles	Extended — approval-link holder
04 Data model	§05 Data model	24 → 18 tables
05 Review workflow	§06 Workflow	Extended — drift verification
06 Google Drive	§03 Drive strategy	Replaced — Picker + drive.file
07 Repository structure	§06.0 Repo shape	Kept
08 API routes	§06.0 Route map	Reduced + approval route
09 Website & leads	—	Cut — partner-led GTM
10 Security gates	§09 Security gates	Rewritten — gates 9 and 17
11 Implementation plan	§07 Delivery plan	Replaced — buffered
12 Vertical slice	§06 Acceptance path	17 steps, revised
13 Trial & demo access	§08 Commercial layer	Manual-first, real project
14 Success metrics	§10 Metrics	Rewritten — link completion
15 Decisions	§12 Decisions	Rewritten — 9 with defaults
Final recommendation	§13 Closing	New positioning

Positioning & scope

One sentence, frozen before any code. A cut feature is removed from the schema and the plan — not hidden behind a flag.

bizzbun gives small creative agencies a clear record of every revision and every client approval, without leaving Drive or WhatsApp. The sentence to freeze first

The wedge is not "cheaper proofing". It is revision-round traceability plus phone-friendly client approval, for agencies that already run on Drive and WhatsApp. Mid-market proofing tools are strong at reviewing files; none of them is built around leaving the files where the agency already works.

Keep

Organizations, roles, tenant isolation
Clients, projects, tasks
Immutable submission rounds
Internal review, explicit publish
Client portal: read, feedback, approve
Drive via Picker + app folders

Cut or defer

Public website and lead inbox
Task dependencies and sub-tasks
Stages tables — label instead
Reports module — CSV export
R2, dashboards, analytics
Full operator console

Add

Revision snapshot per file
No-login approval link
Per-file comment threads
WhatsApp share link
Referral code on organizations
RLS as a second layer

What must be true at pilot exit

A revision creates a new round; the previous round's files are verifiably unchanged, or flagged.
A client records an approval from a phone, without an account.
Internal comments and drafts are absent from every client response.
The agency exports its own records without asking the developer.
One real project has run for 30 days or a full cycle.

Explicitly deferred

Billing automation
Native apps
AI tasks
Capacity planning
Workflow designer
Sheets sync
White-label
Video pin-comments
Self-serve signup
Partner dashboard

A deferred feature returns only by naming the section it displaces.

Architecture

The request path stays deliberately boring. What changes is the Drive path and the addition of a tokenised approval route.

Request path

Cloudflare edge · /api/v1

Agency teamworkspace

Clientapproval link

Clientportal · optional

HTTPS

React + TypeScript SPACloudflare Pages · no secrets

bearer token · or approval token

Cloudflare Workers APIauth · validation · permissions · rules

JWT + org scope · token scope

Supabase Authidentity & sessions

Supabase PostgreSQLRLS as backstop

server-side credentials only

Google Drivepicker + folders

Resendoutbox + retries

Snapshotsrevision or checksum

Drive strategy — replaces pasted links

The v1.0 design could not keep its own promise: it stored links and called the result immutable. Five parts replace it.

Scope: drive.file only. The app sees only files the user picks in the Picker, or files it creates. A restricted scope like drive.readonly triggers verification and a security assessment — not viable for a one-developer pilot, and not a quiet later addition.
The app creates the project folder. Folder ID and URL are stored on the project row.
Files arrive through the Picker. ID, URL, name and MIME type are recorded against the submission. No copy by default.
A snapshot is captured at submission. Drive's revision ID where exposed, otherwise a server-side checksum. Reading an old round re-checks it and shows "file changed since submission" when it no longer matches.
Failure is graceful. Revoked access or a deleted file leaves the round readable, the link marked unavailable, and the API returning a clear error — never a silent 500.

The rule: a previous round must be verifiably unchanged, or the UI must say it is not. Anything less makes "preserved" a claim instead of a fact.

What this does not claim. bizzbun cannot stop a client keeping what they were legitimately shown. It records what was shown, when, and whether it changed — and the agreement says so.

Three boundaries

The Worker is the only trusted boundary: validation, permissions, transitions.
RLS is a backstop, not the primary control. The user's JWT is passed to Supabase.
The database owns state; Drive owns files; neither duplicates the other.

What the browser may know

The anon key and the user's own token.
Only records the API chose to return.
Short-lived authorised file links.
No service role, no OAuth material.

bizzbun/
├── apps/
│   ├── web/    SPA · workspace + link
│   └── api/    Cloudflare Worker
├── packages/
│   └── shared/ schemas · permissions
├── supabase/   migrations · tests
├── tests/      e2e · integration
├── v1/         archived v1.0 page
└── DELIVERY-PLAN.md

Roles

Four membership roles, plus one capability that is deliberately not a role. An approval link cannot browse, list or read anything it was not scoped to.

Owner / Admin ORG_ADMIN

Organization settings
Invite, suspend, remove members
Connect or revoke Drive
Assign roles and audit changes

Project Manager PROJECT_MANAGER

Clients, projects, tasks, assignments
Review submissions, request changes
Approve internally
Publish and generate approval links
Export records

Team Member TEAM_MEMBER

View assigned projects and tasks
Submit files through the Picker
Read feedback, resubmit
Comment where visibility allows

Client PORTAL_MEMBER

Optional

Published submissions only
Client-visible feedback
Recorded approval
Never required for the core loop

Approval-link holder A capability, not a role

A token sees one published submission, leaves feedback and records approval. It cannot list projects, browse submissions or read internal data. It expires, is revocable, is stored hashed, and every access is logged. In the Worker it is a separate authorization path, tested as rigorously as a signed-in user.

Non-negotiables. Invitation and approval tokens are hashed and expiring · internal comments are filtered in the repository layer, not the component · publication is always explicit · role changes are logged · no privileged credential reaches the browser · file access is checked against the user or the token scope · cross-organization access fails closed.

Data model — 18 tables

Twenty-four tables, minus seven dropped, plus one added. Open any table to see its fields and the rule that keeps it honest.

18 tables −7 dropped +1 approval_tokens 3 snapshot fields +1 referral_code

Tenancy & identity

organizations tenant root · +referral_code

iduuid · pk
nametext
slugtext · unique
logo_urltext · null
settingsjsonb
referral_codetext · null
created_attimestamptz

The new field carries manual partner attribution without building partner tables. Trial state lives in settings.

profiles presentation only

iduuid · pk → auth.users
display_nametext
avatar_urltext · null
created_at / updated_attimestamptz

Retained deliberately — one candidate cut list would have removed it, but display names are still needed.

organization_members roles

organization_iduuid · fk · pk
user_iduuid · fk · pk
roleenum
statusenum
joined_attimestamptz

Role: owner, admin, project_manager, team_member. Status: invited, active, suspended, removed.

invitations onboarding

iduuid · pk
organization_iduuid · fk
emailtext
roleenum
token_hashtext · unique
expires_attimestamptz
accepted_attimestamptz · null
created_byuuid

Hash only, expiring, single-use.

Clients

clients account

iduuid · pk
organization_iduuid · fk
name / company_nametext
email / phonetext · null
requirementstext
statusenum
created_byuuid
created_at / updated_attimestamptz

requirements is the brief before a project exists.

client_contacts people

iduuid · pk
organization_iduuid · fk
client_iduuid · fk
name / emailtext
phonetext · null
is_primaryboolean

One primary contact per client, enforced in the API layer.

client_portal_members optional portal

organization_iduuid · fk
client_iduuid · fk · pk
user_iduuid · fk · pk
statusenum
created_attimestamptz

Retained, but no longer the only path — approval links work without a row here.

Delivery

projects delivery

iduuid · pk
organization_iduuid · fk
client_iduuid · fk
name / descriptiontext
statusenum
start_date / due_datedate · null
drive_folder_id / urltext · null
created_by · timestampsuuid · ts

Project and client must share an organization. The folder is created by the app through the Picker flow.

project_members team

project_iduuid · fk · pk
user_iduuid · fk · pk
project_roletext
added_by / created_atuuid · ts

Authorizes work at project level, on top of organization membership.

tasks − parent_task · stage is a label

iduuid · pk
organization_iduuid · fk
project_iduuid · fk
stagetext · check
title / descriptiontext
statusenum
priorityenum
due_attimestamptz · null
created_by · timestampsuuid · ts

parent_task_id removed with sub-tasks. stage_id became a plain label so no foreign key points at a dropped table; changes are logged as stage_changed.

task_assignees assignment

task_iduuid · fk · pk
user_iduuid · fk · pk
assigned_byuuid
assigned_attimestamptz

An assignee must be an active organization and project member.

task_submissions the table being sold

iduuid · pk
organization_iduuid · fk
task_iduuid · fk
round_numberinteger · positive
submitted_byuuid
notestext
statusenum
submitted_attimestamptz
reviewed_by / atuuid · ts · null
review_decisionenum · null
review_notestext · null

Unique (task_id, round_number), and no update route. A correction inserts a new row — that rule is what makes the product trustworthy.

submission_files +3 snapshot fields

iduuid · pk
organization_iduuid · fk
submission_iduuid · fk
drive_file_idtext
drive_urltext
file_name / mime_typetext
snapshot_revision_idtext · null
snapshot_checksumtext · null
snapshot_verified_attimestamptz · null
created_attimestamptz

The three snapshot fields are the fix for the deepest v1.0 defect: without them, "round 1 preserved" is a sentence, not a fact.

task_comments +file_id · per-file threads

iduuid · pk
organization_iduuid · fk
task_iduuid · fk
submission_iduuid · null
file_iduuid · null
author_iduuid
bodytext
visibilityenum
created_attimestamptz

Client queries filter on visibility = 'client' and published submissions, at the repository layer.

approval_tokens new · no-login approval

iduuid · pk
organization_iduuid · fk
submission_iduuid · fk
token_hashtext · unique
expires_attimestamptz
revoked_attimestamptz · null
created_by / created_atuuid · ts
last_accessed_attimestamptz · null

Scoped to exactly one submission. Expired or revoked fails closed before any submission data is read.

Integrations & operations

organization_integrations no refresh-token table

iduuid · pk
organization_iduuid · fk
providertext · unique per org
connection_statusenum
external_account_idtext
scopestext[]
connected_attimestamptz · null

The Picker flow needs no server-side refresh token, so no token table exists. Introducing one reopens the restricted-scope question.

activity_log audit · replaces stage history

iduuid · pk
organization_iduuid · fk
actor_iduuid · null
entity_type / entity_idtext / uuid
actiontext
metadatajsonb
created_attimestamptz

Append-only through application workflows. Stage changes and approval-link access land here.

notification_outbox queue

iduuid · pk
organization_iduuid · fk
event_typetext
payloadjsonb
statusenum
attempt_countinteger
next_attempt_attimestamptz
last_error / sent_attext / ts · null

Carries approval-link emails, change-request notices and trial reminders. Indexed on status and next attempt.

Dropped — and what replaces each

Seven tables removed from v1.0
Dropped	Replacement
`project_stages`	`tasks.stage` label
`project_stage_transitions`	`activity_log` · stage_changed
`task_dependencies`	Deferred entirely
`drive_resources`	`submission_files` + folder on project
`leads` · `lead_events`	Website cut — third-party form
`reports`	On-demand CSV export

Integrity rules the database holds

Project and client share an organization.
Tasks belong to a project in the same organization.
Submissions reference a task in the same organization.
Comments reference a live task, submission and file.
Assignees are active org and project members.
Round numbers are positive and unique per task.
Expired or revoked tokens fail closed.
Related writes run in a transaction.

Indexes to add first

organization_members
  (user_id, status)
clients
  (org_id, status, created_at)
projects
  (org_id, client_id, status)
tasks
  (org_id, project_id, status)
task_submissions
  (task_id, round_number)
approval_tokens
  (token_hash, expires_at)
notification_outbox
  (status, next_attempt_at)

Add an index with the query that needs it. Nothing speculative.

Review, approval & drift

One task loop, two separate approvals — and now a verification step that makes "preserved" provable.

Task created To do · assigned

Work in progress Team member

Submission · round 1 Picker files · notes · snapshot

Changes requested Manager · reason required

Internally approved Agency sign-off

Published + approval link Explicit manager action

Client approves No account required

A change request returns the task to In progress and opens the next round. It never edits the previous one.

Round 1 archived

decision changes_requested
3 files · snapshot recorded
locked — no update route

task_submissions · A1

Round 2 in review

decision pending_review
1 revised file · new snapshot
inherits nothing but the task

task_submissions · B2

Drift check new

re-verify on every read
mismatch shows a warning
record stays intact either way

snapshot_verified_at

Never overwrite. A correction inserts a new row with the next round number. Previous files, notes and decisions stay readable forever.

Publishing is manual. Nothing reaches a client automatically; the manager sees exactly what the client will see.

The drift warning, verbatim. "File changed since submission — the record is intact, but the file content is not." This sentence is the difference between a traceability product and a shared folder with extra steps.

The 17-step acceptance path build first

Before polishing screens, make this pass on staging. It exercises the schema, the permissions, the snapshot mechanism and the one workflow the pilot sells.

Manager signs in.
Manager creates a client.
Manager creates a project — app creates the Drive folder.
Manager creates a task and assigns a member.
Member submits two files via the Picker, with notes.
A snapshot is recorded for each file.
Manager requests changes, with a reason.
Member submits round 2 with one revised file.
Round 1 is preserved and its snapshot reports unchanged.

A user edits the round-1 file in Drive — simulated drift.
The app reports "file changed since submission" on round 1.
Manager approves round 2 and publishes it.
Manager generates an approval link.
A client with no account opens the link and records approval.
The approval lands in activity_log with actor, time and submission.
Another client's project is requested by ID and denied.
A revoked link returns 403 and is logged.

Build sections

Six sections plus the pilot. Each one has a date window, an exit that is either true or false, and a statement of what it must not change.

S0 starts today Build 21 Oct → 8 Jan Break 21 Dec → 1 Jan Pilot 11 Jan → 10 Feb Cadence demo every Wednesday

Section 0

Decisions & five conversations

5 working days 10% of build No code shipped

21 Oct→27 Oct

Freeze the positioning sentence
Roles, statuses, approval meaning
Approval-link decision
Drive strategy proved on the real account
Pilot agency and live project named
Baseline spreadsheet written
Kill criterion written
CA question list sent

Exit criterion

Written decisions exist, and at least 2 of 5 agencies will discuss a target price. Otherwise the kill criterion is invoked.

5 days10% of build

Section 1

Auth, orgs, roles, RLS, Worker

8 working days 17% of build Blocks everything

28 Oct→6 Nov

pnpm monorepo, Vite, Worker
Supabase Auth and sessions
Org, membership, invitation migrations
Tenant authorization middleware
JWT passed to Supabase for RLS
Two-org CI suite

Exit criterion

Cross-organization denial is asserted by an automated test, with RLS active as the second layer.

8 days17% of build

Section 2

Clients, projects, tasks, mobile

10 working days 21% of build First usable surface

9 Nov→20 Nov

Clients and contacts
Projects + Drive folder provisioning
Tasks with stage label
Assignees with membership checks
Server-validated transitions
Mobile workspace at 390 px
Activity log on every mutation

Exit criterion

A manager assigns work and a member moves it from a phone; both appear in the activity log with actor and timestamp.

10 days21% of build

Section 3

Picker, submissions, snapshots

10 working days 21% of build Highest trust value

23 Nov→4 Dec

Google Picker with drive.file
Submission rounds, unique numbers
Snapshot capture and verify-on-read
Drift warning in the UI
Per-file comment threads
Review decisions and corrections
Graceful failure on revoked access

Exit criterion

Editing a round-1 file in Drive produces the drift warning; an untouched file reports unchanged; no route can overwrite history.

10 days21% of build

Section 4

Approval link & portal

10 working days 21% of build Fixes the adoption risk

7 Dec→18 Dec

approval_tokens table and routes
Publish flow with manager preview
No-login feedback and approval form
Optional portal accounts
WhatsApp share link
Outbox notifications
Negative access suite

Exit criterion

A client with no account approves from a phone; revoked and expired links both return 403 and are logged.

10 days21% of build

Planned pause

Two-week break

No delivery commitments Protects the December estimate

21 Dec→1 Jan

No sprints, no demo
Runbook and migrations kept current
Pilot agency told in advance
Buffer is not moved earlier

Why it exists

v1.0 launched a pilot on 14 Dec, days before a holiday dead zone. This version schedules the pause instead of pretending it does not happen.

0 daysnot counted

Section 5

Runbook, export, hardening

5 working days 10% of build No new features

4 Jan→8 Jan

CSV export + file index
Trial rules enforced at the API
Expiry reminder email
Backup and restore drill
Monitoring and alerts
18-gate sign-off
Protected buffer

Exit criterion

A non-developer can export the records, and an expired trial refuses writes — not just hidden buttons.

5 days10% of build

Nothing in a section depends on a later section. If S3 is cut, the traceability claim cannot ship and S4's publish flow is pointless — §07.2 states exactly which sections survive a cut.

Dependencies and what can be cut

Cutting a section has consequences — state them before cutting
If cut	Cannot ship	Still ships
S3 snapshots	The traceability claim; S4 would publish unverifiable history	S0–S2, S5
S4 approval link	The adoption metric; approval becomes an email loop	S0–S3, S5
S2 mobile workspace	Team submissions in the pilot	S0–S1, S3, S4
The two-week break	The protected buffer	Everything — pilot starts 18 Jan instead

Definition of done · every section

Merged with a committed migration.
Permissions covered by an automated test, including a cross-org negative test.
Checked at 390 px before it is called finished.
Important mutations write an activity_log entry.
Runbook updated the same day.
Snapshot behaviour tested in any section touching submissions.

Schedule

Ten build weeks at part-time pace, a deliberate two-week break, then a measured pilot. Every row is a calendar week, and every date here also appears on the section card that owns it.

Ten build weeks, one break, one pilot · exact dates per section
Week	Dates	Sections	Milestone
W1	21–23 Oct	S0 decisions	—
W2	26–30 Oct	S0 closes · S1 starts	M0 · 27 Oct
W3	2–6 Nov	S1 foundation	M1 · 6 Nov
W4	9–13 Nov	S2 delivery core	—
W5	16–20 Nov	S2 delivery core	M2 · 20 Nov
W6	23–27 Nov	S3 traceability	—
W7	30 Nov–4 Dec	S3 traceability	M3 · 4 Dec
W8	7–11 Dec	S4 approval link	—
W9	14–18 Dec	S4 approval link	M4 · 18 Dec
—	21 Dec–1 Jan	Planned pause	No demos
W10	4–8 Jan	S5 runbook and hardening	M5 · 8 Jan
Pilot	11 Jan–10 Feb	One real project, no demo data	M6 · 11 Jan · M7 · 10 Feb

Forty-eight working days across ten build weeks, plus a two-week planned break and a 30-day pilot. Every date in this table also appears on the section card that owns it.

Milestones

Tue 27 Oct · M0 Scope and price tested
Decisions frozen; two agencies willing to talk price; Drive strategy proved on the real account.
Fri 6 Nov · M1 Tenancy proven
Cross-org denial asserted in CI with RLS active.
Fri 20 Nov · M2 Vertical slice on a phone
Assign, update, logged — at 390 px.
Fri 4 Dec · M3 Drift detected
History cannot be overwritten; a changed file is flagged.

…and the gates that matter

Fri 18 Dec · M4 Client approves without an account
Link completion is the metric; revoked and expired tokens fail closed.
Fri 8 Jan · M5 Handover ready
Export, restore drill and 18 gates signed.
Mon 11 Jan · M6 Pilot begins
One real project, imported before day 1. No fictional data.
Wed 10 Feb · M7 Pilot exit review
Scorecard measured against pre-pilot baselines.

MONThree outcomes

Pick three outcomes, not fifteen tickets. Re-read the risk table and confirm the week's demo target.

WEDDemo the workflow

Fifteen minutes with the pilot lead on working software. If a screen needs explaining, it isn't finished.

FRIShip and write it down

Deploy, migrate, record decisions, update the runbook. Friday's notes are Monday's head start.

Release check, Fri 8 Jan. No new code. Open every project from a client account, revoke a token, edit a submission file in Drive, restore a backup, and send a real notification to a real inbox.

Commercial layer, manual first

v1.0 deferred billing while promising trial-to-paid and referral commissions. This version writes both down and runs them by hand — no billing code in the pilot.

01Trial and payment

Guided pilot: 30 days or one project cycle.
First 3–5 agencies invoiced manually.
"Convert to paid" = same org, same IDs, manual invoice, flag lifted.
Subscription code only after paying customers exist.

02Referral, not resale

Customer pays bizzbun; bizzbun pays the agency.
~20% recurring for 12 months, one page.
Tracked with referral_code plus a spreadsheet.
Partner dashboard only after 3+ active partners.

03Retention, in plain language

30-day read-only window after the pilot.
Export is CSV plus a file index.
Deletion runs on a schedule and logs its work.
Clients may keep what they were shown — the agreement says so.

04Compliance minimum

Privacy policy, terms, DPA.
Retention, export and deletion documented.
Breach-response procedure.
Restore drill completed before real client data.

Choose referral before the first partner conversation. Resale makes the agency a party in the data chain and changes the compliance analysis — do not choose it without legal input.

Benchmarks are quarantined. Trial-conversion figures quoted in the reviews are vendor-published, with no B2B or length context. They are not targets for a guided pilot; they belong to a later self-serve experiment.

Metrics & security gates

Baselines are captured by hand before day 1. v1.0 said "capture week 1", but week 1 had no product in it.

≤2 Review rounds per task

3d Submission to internal approval

70% Approval links completed

<1 Manual chases per week

Pilot scorecard · reviewed 10 Feb 2027
Measure	Source	Target	Baseline
Assigned to first submission	task_submissions	under 2 days	manual, pre-pilot
Review rounds per task	task_submissions	2 or fewer	manual, pre-pilot
First submission to approval	task_submissions	under 3 days	manual, pre-pilot
Approval-link completionNew — replaces the portal-account target	approval_tokens + log	70% of links	n/a — new
Approval without an account	approval_tokens	majority	n/a — new
Drift detections	snapshot_verified_at	tracked, not targeted	n/a — new
Manual chases per project	team log	under 1 / week	manual, pre-pilot

Dropped: "80% of invited clients active". It measured account creation, not the behaviour the pilot exists to change.

Eighteen gates before real client data

Trial status and token expiry are authorization rules. Both fail closed at the Worker before any submission data is read. Hiding a button in React is not access control.

Risks & assumptions

Nine re-rated risks and five open assumptions. Anything still open at its deadline moves the plan explicitly.

Reviewed every Friday · owner is the developer unless stated
Risk	Likelihood	Impact	Mitigation
Schedule slip from real availabilityExams, client work, holidays	High	Pilot date moves	Weekly hours in README; re-baseline before S1 ends; the date moves once, visibly.
Drive content driftA file edited behind a link	Medium	Traceability claim collapses	Snapshot at submission; verify on read; drift warning; copy fallback.
Client adoptionClients won't create accounts	High	Pilot metrics meaningless	No-login link is the primary path; measure link completion.
Restricted-scope temptation"Just add drive.readonly"	Medium	Verification delay	drive.file only; a restricted scope is a scope change with a cost.
Cross-organization exposureOne unscoped query	Medium	Trust-ending	Worker filter everywhere; RLS backstop; two-org CI; access review in S5.
Approval-token leakageGuessing or over-scoping	Low–Medium	Unauthorised view	Hashed, single-submission, expiring, revocable, logged, negatively tested.
Commission or tax surpriseGST, TDS, fee changes	Medium	Margin loss	CA input before the first payout; current fees confirmed before pricing.
Pilot disrupts real client work	Medium	Agency withdraws	Tools run in parallel; 15-minute weekly check-in; no forced migration.
Single developer unavailable	Medium	1–2 week slip	Protected buffer; migrations and runbook current so someone else can deploy.

Assumptions register

Open assumptions with a deadline, not an opinion
ID	Assumption	Verify by	If wrong
A1	drive.file is non-sensitive and sufficient with the Picker; pasted links fall outside it	Live test, S0	Snapshot-copy design, or accept restricted-scope cost
A2	Drive exposes a stable revision ID for the pilot's file types	Sample 10 files, S0	Checksum fallback, then read-only copy
A3	20–25 focused hours per week through December	Calendar check, before S1	Extend the build; move the pilot once
A4	DPDP obligation dates quoted in the reviews	Counsel or gazette	Adjust the compliance minimum
A5	Razorpay add-on and competitor pricing	Vendor pages, before invoice	Re-price; no code depends on it

Decisions

Nine answers, each with a working default so the build never waits on a meeting. Answers 1–4 change the schema or the workflow and cannot stay open past S0.

Owner · pilot lead · record the answer in the decision log
#	Decision	Default	Due
1	Drive strategy	Picker + drive.file + snapshot, proved on the real account	27 Oct
2	Client approval path	No-login link primary; account optional	27 Oct
3	Meaning of approval	Recorded acknowledgement; not a legal e-signature	27 Oct
4	Who publishes	Manager, manually, per submission	27 Oct
5	Referral or resale	Referral, ~20% recurring for 12 months	Before partner talk
6	Pilot agency and project	Named, with a confirmed start date	27 Oct
7	Weekly hours	Write the real number in the README	Before S1
8	Kill criterion	Fewer than 2 of 5 will discuss price → stop or re-wedge	27 Oct
9	End-of-pilot behaviour	30-day read-only, export, then deletion	Before pilot day 1

A default is not final. Every row has a working answer so the plan advances on time. If the lead overrides one, the date it lands moves the section that depends on it — visibly.

This week · 20–23 October

Tue 20 Oct — freeze the positioning sentence and the keep/cut/add scope.
Wed 21 Oct — confirm the pilot agency, the real project and the check-in person; write the kill criterion.
Thu 22 Oct — Drive spike on the real account: Picker, drive.file, folder creation, revision-ID availability.
Thu 22 Oct — write the baseline spreadsheet; book the five agency conversations.
Fri 23 Oct — send the CA question list. Do not open S1 until two conversations indicate a price discussion.

Every revision and every approval, on the record.

01Shrink the build

02Fix the trust claim

03Client approval without an account

04An honest schedule

Validation register

Nothing from v1.0 disappears silently

Keep

Cut or defer

Add

What must be true at pilot exit

Explicitly deferred

Request path

Drive strategy — replaces pasted links

Three boundaries

What the browser may know

Approval-link holder A capability, not a role

Tenancy & identity

Clients

Delivery

Integrations & operations

Dropped — and what replaces each

Integrity rules the database holds

Indexes to add first

Round 1 archived

Round 2 in review

Drift check new

The 17-step acceptance path build first

Decisions & five conversations

Auth, orgs, roles, RLS, Worker

Clients, projects, tasks, mobile

Picker, submissions, snapshots

Approval link & portal

Two-week break

Runbook, export, hardening

Dependencies and what can be cut

Definition of done · every section

Milestones

…and the gates that matter

MONThree outcomes

WEDDemo the workflow

FRIShip and write it down

01Trial and payment

02Referral, not resale

03Retention, in plain language

04Compliance minimum

Eighteen gates before real client data

Assumptions register

This week · 20–23 October