One operating platform for Australian residential builders.
From contract to handover to warranty — BuildTrace AU brings the builder, their team, their customers, and their trades into a single workspace. Documents stop getting lost. Variations stop getting forgotten. Trades get clear jobs with clear evidence. Customers see exactly where their home is in the build, every day.
A subscription platform for the full residential build lifecycle.
BuildTrace AU is a multi-tenant SaaS for Australian residential builders. It replaces email threads, scattered spreadsheets, and legacy ticketing tools with a single shared workspace where customers, trades, and the builder's internal team all see the right view of the same project.
| Today (without BuildTrace) | With BuildTrace AU |
|---|---|
| Documents scattered across email threads, Dropbox folders, and WhatsApp chats — no one knows which version is current | One vault — every document versioned, role-filtered, and always findable by the right person |
| Variations agreed verbally on site, then disputed at handover when no one can remember the exact terms | Variations raised in-app with cost + time impact; customer approves with a tap; full audit log from day one |
| Trades booked by phone tag and SMS — confirmations lost, no-shows with no record | In-app trade bookings with push notification — accept or decline, calendar-confirmed, no lost messages |
| Customers constantly chase the office for updates on where their home is in the build | Customers see live build stage, photos, and pending actions on their own portal — zero phone calls |
| No audit trail when something goes wrong — finger-pointing, no timestamps, no evidence | Every action timestamped and attributed; one-click audit pack for disputes, finance, or lenders |
| Site supervisor hand-writes daily reports on paper or in scattered notes apps | Mobile-first site board with photo evidence and supervisor sign-off — no paper, no lost notes |
Every document, one place
Contracts, plans, certificates, invoices, photos — uploaded once, versioned, role-filtered. Customers see what they're meant to see; trades see only what they need; nothing gets lost between Outlook threads and Dropbox links.
Every change, traceable
Variations, document requests, site questions, warranty items — each one has a status, a cost impact, a time impact, and a full audit trail. Customers approve in-app. Builders close the loop with one click.
Built for the site, not the desk
Supervisors and trades work on phones. Mobile-first views, bottom-tab navigation, completion-with-photos. Offline document access on poor-connectivity sites is part of the Phase 2 plan.
Three user groups, one shared workspace.
The builder is the tenant — they pay the subscription and run the company inside the platform. They invite service providers (trades) and homeowners per project. Externals are always free and never count toward seats.
The builder Tenant · pays subscription
The builder's company is the BuildTrace AU tenant. The owner, their team, and on-site supervisors all live inside this tenant and share visibility across every project the builder runs.
Builder admin Tenant owner
The builder running the company. Full visibility, full control of the tenant.
- Creates projects, invites customers & trades
- Approves variations & shared documents
- Exports audit pack for finance & lenders
- Manages the team & subscription
Builder employee Internal
Office staff, accounts, project coordinators. Scoped permissions but full project visibility.
- Triages customer requests
- Manages documents & bookings
- Tracks progress against milestones
- No billing / subscription control
Site supervisor Internal
The on-site lead. Daily task board, evidence capture, blocker resolution. Mobile-first.
- Site board with today's tasks
- Required-evidence checklist per stage
- Confirms or escalates blockers
- Signs off trade completions
Service providers Free · invited per project
Every trade and specialist who touches a project. One account works across multiple builder tenants — invited per project, no signup friction, never count toward seats.
How service providers work in the platform
- Mobile-first job queue — site address, scope, due date, access window
- Booking accept / decline with reason captured
- Complete-with-photos sign-off; supervisor verifies
- One account spans multiple builder tenants
- No commercial / customer info exposed — only assigned work
- Notifications: email + push (Phase 1.5), SMS (Phase 2)
Trade categories — typical examples
Each ✓ marks when a trade is typically active during an Australian residential build. Rows are ordered by when each trade enters the build — earliest stages at the top — so the active pattern forms a staircase down the matrix.
| Trade | Typical examples | Pre-construction | Base | Frame | Lock-up | Fixing | Practical completion | Handover |
|---|---|---|---|---|---|---|---|---|
| 🚜 Site & earthworks | Excavators, surveyors, demolition, levellers | ✓ | ✓ | |||||
| 🧱 Concrete & masonry | Concreters, bricklayers, steel fixers | ✓ | ✓ | |||||
| 🔧 Plumbing & gas | Plumbers, gas fitters, waterproofers | ✓ | ✓ | ✓ | ✓ | |||
| 🔨 Carpentry & framing | Framers, formworkers, finish carpenters | ✓ | ✓ | |||||
| ⚡ Electrical | Electricians, data & comms, solar installers | ✓ | ✓ | ✓ | ✓ | |||
| 🏠 Roofing & cladding | Roof tilers, metal roofers, gutter, cladders | ✓ | ||||||
| 🪟 Glazing | Windows, shower screens, splashbacks | ✓ | ✓ | |||||
| ❄️ HVAC & insulation | Split-system, ducted heating/cooling, insulation | ✓ | ✓ | |||||
| 🟫 Tiling & waterproofing | Wet-area tilers, screeders, balcony WP | ✓ | ||||||
| 🪵 Joinery & cabinetry | Cabinetmakers, kitchen installers, wardrobes | ✓ | ✓ | |||||
| 🎨 Painting & plastering | Painters, plasterers, renderers | ✓ | ✓ | |||||
| 🌿 Landscaping & external | Paving, fences, decks, retaining walls | ✓ | ✓ |
Homeowners Free · single project
The end customer — the family commissioning the build. They see only their project, approve changes that affect cost or timeline, and download documents the builder chooses to share.
What they see
- Live progress on their build (stage timeline + photos)
- Documents shared by the builder — contract, plans, certificates, handover pack
- Variation requests awaiting their approval, with cost & time impact visible
- Messages from the builder
What they can do
- Raise a variation, document request, or site question
- Approve or reject changes in-app — every decision logged
- Download a lender-ready evidence pack on demand
- Raise warranty / defect items post-handover
Three workflows that anchor the platform.
If the demo lands, it's because these three flows feel obvious. Each is built around one transcript-validated pain point: lost documents, untraceable variations, and unscheduled trades.
1 · Variation approval — the demo's anchor scenario
A customer wants to upgrade the kitchen benchtop after framing. Today: that lives in an email thread, gets agreed verbally, then disputed at handover. With BuildTrace AU:
Customer raises
Title + details, attaches reference photo. Category auto-suggested.
Builder reviews
Sets cost impact (AUD) & time impact (days). Adds internal note.
Customer approves
Approves in app. Or rejects with reason — request re-negotiates.
Audit logs
Every state change attributed, timestamped, exportable as PDF.
2 · Service-provider booking — trade scheduling done right
Verbatim transcript pain: "plumber booking, time appointment, notification, plumber goes and does the work". Today: phone tag and SMS. With BuildTrace AU:
Builder books
Picks a trade from the project's roster, sets a window.
Trade notified
Email + push: project, address, scope, due date. One tap to view.
Trade accepts
Or declines with a reason. Calendar entry confirmed.
On-site sign-off
Completion with photos. Supervisor verifies. Customer sees stage progress automatically.
3 · Document upload — visibility filtered by role
The sharpest pain we heard: "documents lie around everywhere, no way for anyone to reference them." One vault, one upload, four filtered views.
Upload
Builder or supervisor uploads. Sets visibility: customer / internal / restricted.
Versioned
Replace = new version. Older versions kept; latest marked.
Role-filtered
Customer sees customer-only. Trade sees task evidence. Builder sees everything.
Audit pack
Export project's shared documents as a PDF bundle for lender / handover.
How BuildTrace AU is built — at a glance.
Modern web stack: React on the front, FastAPI on the back, PostgreSQL with row-level security underneath. The whole system is multi-tenant from day one — one builder's data can never leak into another's.
System overview
| Layer | Component | Port / Tech | Purpose | Phase |
|---|---|---|---|---|
| Client | Mobile PWA | — | Supervisor & trade users on phones | — |
| Client | Desktop browser | — | Builder admin / employee — office | — |
| Client | Inbound email webhook | — | Customer emails auto-converted to requests | P2 |
| Application | React 19 + Vite | 3000 (dev) | Frontend — TanStack Router, Shadcn, Tailwind | — |
| Application | FastAPI + uvicorn | 8000 | API server — JWT auth, role deps, Pydantic strict | — |
| Application | Temporal Worker | 7233 gRPC | Email ingest, OCR, notification dispatch | P2 |
| Infra | PostgreSQL 16 + RLS | 5432 | Primary DB — row-level security (tenant isolation point) | — |
| Infra | Redis 7 | 6379 | Notification queue, cache | — |
| Infra | MinIO | 9000 / 9001 console | Document vault — S3-compatible, presigned uploads | — |
| Infra | SMTP (Postmark) | external HTTPS | Transactional email | — |
| Infra | SMS (Twilio) | external HTTPS | SMS notifications | P2 |
| Infra | Anthropic API | external HTTPS | Claude Sonnet — request categorisation, semantic search | P1.5 |
Frontend routes
Frontend route tree
Every route in the React app, who can reach it, and what's special. Mobile users (trade and supervisor) deep-link directly to /jobs and /site for bottom-tab navigation.
| Route | Public? | Required user type / role | Notes |
|---|---|---|---|
/ |
✓ | none | Public landing |
/login |
✓ | none | — |
/register |
✓ | none | — |
/accept-invite/:token |
✓ | none | Magic link |
/forgot-password |
✓ | none | Phase 1.5 |
/_authenticated |
any authenticated | Layout guard with beforeLoad |
|
/_authenticated (index) |
any authenticated | Role-aware redirect | |
/projects |
builder_owner / employee | — | |
/projects/:projectId |
ProjectMember or internal | Project tab shell | |
/projects/:projectId/documents |
as project | Visibility-filtered list | |
/projects/:projectId/requests |
as project | — | |
/projects/:projectId/tasks |
internal / supervisor | — | |
/projects/:projectId/bookings |
internal | Phase 1.5 | |
/projects/:projectId/audit |
builder_owner / employee | — | |
/home |
homeowner | Single-project home portal | |
/jobs |
trade | Job queue | |
/jobs/:taskId |
trade (assigned) | — | |
/site |
supervisor (ProjectMember) | Site board | |
/reports |
builder_owner / employee | — | |
/settings/profile |
any authenticated | — | |
/settings/tenant |
builder_owner | — | |
/settings/team |
builder_owner / employee | — | |
/settings/notifications |
any authenticated | — | |
/notifications |
any authenticated | — |
Multi-tenant model
Every user the platform models, by tenant attachment. Read down to see how each role joins the system; read across the indicator columns to see the seat-counting and cross-builder rules at a glance.
| User type | tenant_id | Joined via | Counts toward seats | Can span multiple builders | Example (demo) |
|---|---|---|---|---|---|
| Builder owner | Direct | direct | ✓ | Nisha | |
| Builder employee | Direct | direct | ✓ | Office staff | |
| Site supervisor | Direct | direct | ✓ | Mia Clarke | |
| Consultant / channel partner | Direct | direct | ✓ | — | |
| Homeowner / customer | NULL | ProjectMember | Rare | Ava Harris | |
| Trade partner | NULL | ProjectMember | ✓ | Dave the plumber | |
| Network admin Phase 2 | Network tenant | direct | ✓ | reads all | — |
Internal users (top four rows) attach directly to a single builder tenant and consume seats. External users (homeowners and trades) carry no tenant_id of their own — they attach per project via the ProjectMember table, are always free, and a trade can span multiple builder tenants with a single account. Network admin sits on a separate "network" tenant tier that reads all builder tenants in its network — Phase 2 scope.
Core data model — 11 entities
Every row in every table carries a tenant_id. Postgres row-level security (RLS) acts as a backstop — even if application code forgets the tenant filter, the database refuses to return another tenant's row.
| Entity | Purpose | Key fields | Tenant scope | Versioned | Notes |
|---|---|---|---|---|---|
Tenant |
One row per builder company. | slug, abn, plan, name |
— | — | Root of the RLS hierarchy; all other scoped tables reference this. |
User |
Any person with an account — builder staff or external party. | email, phone, role, tenant_id |
NULL if external | — | Externals have tenant_id = NULL; role enum: builder_owner, employee, homeowner, trade, consultant. |
Project |
A single house build, owned by a tenant. | tenant_id, phase, stage, site_address |
✓ | — | Phase: pre_construction / during_build / mci / warranty. 8 AU construction stages. |
ProjectMember |
Attaches an external user to a project with a role. | project_id, user_id, role |
— (join) | — | Join table. Lets one trade account span multiple builder tenants without a seat charge. |
Document |
Files attached to a project with visibility control. | visibility, version, minio_key, project_id |
✓ | ✓ | Visibility: customer / internal / restricted. Stored in MinIO, indexed in Postgres. |
Request |
Formal workflow item raised against a project. | type, status, cost_impact, time_impact |
✓ | — | Types: Variation · Document request · Site question · Warranty item. Full status lifecycle. |
Task |
Work item assigned to a trade or supervisor. | assignee_id, due_date, evidence_required, status |
✓ | — | Evidence requirements enforce photo/sign-off before close. |
Booking |
A trade's scheduled site visit. | trade_id, scheduled_at, status, project_id |
✓ | — | Status lifecycle: propose → accept → complete. Calendar-aware. |
AuditEvent |
Immutable log of every state change across the system. | actor_id, action, target, occurred_at |
✓ | — | Payload snapshot stored per event. Append-only; never updated. |
Notification |
Outbound alerts across all channels per user preference. | channel, user_id, event_type, sent_at |
✓ | — | Channels: email · SMS · in-app · push. Per-user, per-event-type opt-in/out. |
Invite |
Magic-link tokens for onboarding customers and trades. | token, project_id, role, expires_at |
✓ | — | Eliminates forced self-signup friction. Token consumed on first use. |
What existing VPS projects can safely accelerate BuildTrace AU.
BuildTrace AU is a new product and needs its own builder/project/document/variation model. But the VPS already contains proven SaaS, workflow, file-upload, PWA, and GTM patterns we can reuse carefully. The rule is simple: reuse infrastructure and battle-tested patterns; do not copy old domain assumptions.
/root/projects/starter-kit as the real app foundation, then selectively adapt WorkBuddy, Process App / Orderly, VMI, Prop Capture, Marketing Engine, and SiteGen patterns where they reduce risk. The full engineering note is saved at docs/VPS_REUSE_AUDIT.md.
Starter kit Copy / adapt
/root/projects/starter-kit is the highest-value base because it already matches the planned BuildTrace stack: React 19, TanStack Router/Query, Shadcn, Vite, FastAPI, SQLAlchemy async, Alembic, Postgres, pnpm workspace, and shared Zod types.
- Use as the
app/scaffold - Reuse JWT auth, tenants, backend/frontend layout
- Reuse tests, Docker infra, shared-types package
- Modify user model for external ProjectMember access
WorkBuddy Adapt patterns
/root/projects/workbuddy is the most mature SaaS on the VPS. It should inform tenant isolation, safe attachments, mobile-first field UX, geotag evidence, staging/deployment discipline, and security tests.
- Safe attachment validation from
backend/src/services/files/storage.ts - Tenant-isolation lessons from RLS/security tests
- Mobile location/evidence UI ideas
- Do not copy CRM/call-report domain models
Process App / Orderly Adapt patterns
/root/projects/process-app is useful for approvals, staged workflows, PWA/offline shell, document upload UI, and later semantic document search. Use pieces; avoid importing the full hard-blocking engine in Phase 1.
- Approval lifecycle for variations and customer sign-off
- Document upload zone for PDFs/images/text
- PWA service worker and offline cache approach
- RAG/document chunks only for Phase 2 search
VMI Small patterns
/root/projects/vmi helps with internal/external role separation, audit trails, workflow tests, and proposal generation. It is single-tenant custom software, so it must not become the BuildTrace architecture.
- Audit logger pattern from
apps/api/src/lib/audit.ts - External portal thinking: vendor → trade/homeowner
- Playwright role-based e2e workflow tests
- Proposal/PDF assets for sales collateral
Prop Capture Later
/root/projects/prop-capture and /root/projects/prop-capture-web are useful only for future document intelligence: PDF extraction, image extraction, OCR, plan parsing, and AI search inside uploaded project documents.
- Useful for Phase 2 OCR/document extraction experiments
- Not a SaaS foundation
- Do not add this before the document vault is working
Marketing Engine / SiteGen GTM only
/root/projects/marketing-engine, /root/projects/sitegen, and /root/projects/konzult-self-hosted can help with landing pages, outreach copy, proposals, PDFs, and sales assets — not core app code.
- Use for proposal and landing-page collateral
- Use for GTM experiments and shareable sales pages
- Keep marketing code separate from the product app
File-level reuse shortcuts
| Need in BuildTrace | Best source on VPS | How to use it |
|---|---|---|
| App scaffold | /root/projects/starter-kit | Copy/adapt into /root/projects/buildtrust-au/app; rename packages to @buildtrace/*. |
| Auth and tenant baseline | starter-kit/apps/api/app/services/auth.pystarter-kit/apps/api/app/routes/auth.py | Reuse structure for login, refresh, JWT payload, password hashing; adapt roles and external-user rules. |
| Safe document uploads | workbuddy/backend/src/services/files/storage.ts | Port the magic-byte MIME validation concept into FastAPI before accepting PDFs/images/site evidence. |
| Tenant isolation tests | workbuddy/backend/src/tests/security/tenant-isolation.test.ts | Copy the lesson: if RLS uses DB session variables, use transaction-scoped tenant context to avoid pooled-connection leaks. |
| Approval lifecycle | process-app/orderly-api/src/services/approval-service.ts | Adapt a simpler version for BuildTrace variations: requested → priced → customer-approved/rejected → closed. |
| Document upload UI | process-app/orderly-app/src/components/workflow/DocumentUploadZone.tsx | Adapt drag/drop upload for document vault and photo evidence once React app exists. |
| PWA/offline shell | process-app/orderly-app/src/sw.ts | Use the Workbox cache strategy as reference for cached document list and later offline read. |
| Audit trail | vmi/apps/api/src/lib/audit.ts | Port the concept into FastAPI: actor, action, entity type, entity id, old/new value, timestamp, IP. |
| External portal UX | vmi/apps/web/src/routes/vendor/ | Reference for scoped external views; translate vendor portal into trade/homeowner portal. |
| OCR / document intelligence | prop-capture, prop-capture-web | Keep for Phase 2 when semantic document search and plan/PDF parsing become priorities. |
What must stay new
✅ Reuse safely
- Starter-kit monorepo shape and FastAPI patterns
- Auth/token/tenant scaffolding, after role-model changes
- WorkBuddy-style safe file upload checks
- Orderly-style approval lifecycle and PWA shell
- VMI-style audit logging and external-portal test discipline
⚠️ Use later / with caution
- Orderly RAG/document chunking — Phase 2 semantic search only
- Prop Capture OCR/PDF parsing — after document vault is stable
- WorkBuddy local disk storage — okay as pattern, but BuildTrace should prefer S3/MinIO abstraction
- Marketing Engine/SiteGen — GTM assets only, not app code
🚫 Do not reuse
- WorkBuddy CRM, call-report, sales-pipeline models
- VMI BOM, matcode, vendor-inventory models
- ERP manufacturing/inventory domain code
- Old osTicket-style ticketing assumptions
- Any single-tenant custom-app architecture
- Full generic workflow engine before MVP proves it needs one
Recommended implementation sequence
Scaffold
Create app/ from starter-kit and rename packages to @buildtrace/*.
Model roles
Internal users get tenant_id; homeowners/trades use ProjectMember.
Core entities
Tenant, User, Project, ProjectMember, Document, Request, Task, AuditLog.
Add proven patterns
Safe file uploads, audit logger, simple approval lifecycle, then PWA shell.
From static demo to full operating platform.
The static HTML demo is for client validation. The React build delivers in phased slices — each shippable, each adding capability without breaking what came before.
What ships in each phase — read down to see scope, read across to see when a feature lands.
| Deliverable | Phase 1 — Foundation 🔒 Locked 4 weeks · 4 sprints | Phase 1.5 — Mobile + AI Next 2 weeks | Phase 2 — Notifications & reports After pilot 4 weeks | Phase 3 — Compliance & accounts Open-ended Post-pilot roadmap |
|---|---|---|---|---|
| Multi-tenant auth + JWT + invite flow | ✓ | |||
| Projects + ProjectMember | ✓ | |||
| Document vault (versioning + visibility filter) | ✓ | |||
| Variations & request audit trail | ✓ | |||
| Customer portal + builder dashboard | ✓ | |||
| Postgres row-level security | ✓ | |||
| Mobile-first views (supervisor + trade) | ✓ | |||
| PWA shell (installable, cached doc list) | ✓ | |||
| Service-provider booking flow | ✓ | |||
| AI auto-categorise inbound requests (Claude) | ✓ | |||
| Photo evidence capture | ✓ | |||
| Email / SMS / push notifications | ✓ | |||
| Email-to-ticket ingestion | ✓ | |||
| Reports (volumes, approval delays, trade response) | ✓ | |||
| Network admin (cross-builder portfolio) | ✓ | |||
| Full offline document read | ✓ | |||
| Semantic document search (AI) | ✓ | |||
| Pre-construction compliance (NSW-first) | ✓ | |||
| Accounts: invoices, deposits, progress claims, lender evidence | ✓ | |||
| Material / vendor management | ✓ | |||
| Integrations: Xero, MYOB, e-signature | ✓ | |||
| Advanced AI (defect routing, drafted replies) | ✓ |
Phase 1 sprint timeline
Three tiers, all in AUD, all monthly.
Builders pay; the people they invite — homeowners and trades — don't. Pick a tier based on team size; nothing else changes the experience.
Solo
- 1–3 builder users
- Unlimited customers & trades
- Up to 5 active projects
- Document vault & variations
- Audit pack export
- Mobile field views
Pro
- Up to 10 builder users
- Unlimited customers & trades
- Unlimited active projects
- Everything in Solo
- Reports & trade performance
- Priority support
- AI auto-categorisation (P1.5)
- Pilot customer (Nisha) on annual Pro with founding-customer benefits.
Network
- Unlimited builder users
- Everything in Pro
- Cross-builder portfolio view (P2)
- Network admin dashboards (P2)
- White-label option
- Dedicated onboarding
What's included at each tier
| Feature | Solo | Pro Recommended | Network |
|---|---|---|---|
| Monthly price (AUD) | $149 | $399 | $899 |
| Builder users included | 1–3 | Up to 10 | Unlimited |
| Active projects | Up to 5 | Unlimited | Unlimited |
| Customers & trades (external users) | Unlimited · free | Unlimited · free | Unlimited · free |
| Document vault (versioning + visibility filter) | ✓ | ✓ | ✓ |
| Variations + audit trail | ✓ | ✓ | ✓ |
| Mobile field views (PWA) | ✓ | ✓ | ✓ |
| Audit pack export | ✓ | ✓ | ✓ |
| Trade booking flow | Phase 1.5 | Phase 1.5 | Phase 1.5 |
| AI auto-categorise (request classification) | Phase 1.5 | Phase 1.5 | Phase 1.5 |
| Reports & analytics | — | ✓ | ✓ |
| Priority support | — | ✓ | ✓ |
| Cross-builder portfolio view | — | — | Phase 2 |
| Network admin dashboards | — | — | Phase 2 |
| White-label option | — | — | ✓ |
| Dedicated onboarding | — | — | ✓ |
Click through a real workflow.
The clickable demo is a static preview — accounts and data are fixtures, no backend yet. Use it to feel the variation-approval flow, role-switching, and document vault. The React build replaces it with the real platform in Phase 1.
Open the BuildTrace AU demo
Switch between Builder admin, Customer, Site supervisor, and Trade roles using the demo account switcher in the sidebar. Try raising a request, approving a variation, and viewing the audit trail.
Project status & open items (internal review)
Status dashboard
Sales-cycle progression
Sales-cycle state machine (where we are with the deal)
| Stage | Status | Blocker | Next action |
|---|---|---|---|
| Discovery | ✅ Done | — | Transcripts captured (Chinmay + 2× Saurabh calls). Pain points validated: doc mgmt, booking, legacy tools. |
| Mahinder demo | ⏳ Pending | §2.6 pricing not locked — can't quote without AUD/seat tier decided. | Schedule call. Demo: static HTML at buildtrace.konzult.in. |
| Nisha demo | ☐ Blocked | §2.1 (is Nisha the builder?) and §2.2 (same Nisha as prior osTicket?) unresolved. | After Mahinder demo. Affects contract entity + pitch framing. |
| Proposal | ☐ Not started | Pricing tier (§2.6), timeline (§2.7), clear scope boundary (Phase 1 only). | After Nisha demo. |
| Pilot (Phase 1 build) | ☐ Not started | Proposal signed. | Nisha = tenant 0001. ~4-week build. Goal: builder admin + homeowner + docs + variations live. |
| Live (Phase 2 onwards) | ☐ Not started | Pilot live in production. | Booking flow, notifications, email-to-ticket. Network admin (§2.3) unlocked here. |
| Network growth | Future | Need additional builder tenants. | Mahinder's alumni network → cross-tenant portfolio view active. |
Decisions register
| Ref | Decision | State | Working assumption |
|---|---|---|---|
| §2.1 | Is Nisha the builder, or working with one? | Parked | Assumed she is the builder; Phase 1 code unaffected either way. |
| §2.2 | Same Nisha as previous osTicket client? | Parked | Assumed different client — net-new sale. |
| §2.3 | Network admin in Phase 1? | Locked | Phase 2. Single-builder pilot first. |
| §2.4 | PWA / offline capability v1? | Locked | Shell in P1, cached list in P1.5, full offline in P2. |
| §2.5 | First AI feature? | Locked | Auto-categorise inbound requests in P1.5. |
| §2.6 | Pricing tiers (AUD per month)? | Locked | Solo $149 · Pro $399 (anchor) · Network $899. Externals free. Mahinder $500/$1,000 finder's fee. |
| §2.7 | Firm timeline commitment? | Parked | 4w P1 + 2w P1.5 + 4w P2; renegotiate with Nisha. |
| §2.8 | Multi-tenant from v1? | Locked | Yes — tenant_id everywhere, ProjectMember for externals. |
What's good · what's open · what needs correction
✅ What's good
- Scope is reframed correctly (operating platform, not a ticketing tool)
- Multi-tenant data model handles the "trade works across builders" reality
- Document vault directly addresses the sharpest transcript pain
- Variation flow is the anchor demo scenario — feels real
- Pricing is settled with a defensible anchor (Pro $399)
- Both Claude Code and Codex read the same context file (CLAUDE.md ↔ AGENT.md)
⚠️ What's open
- Site supervisor role isn't strongly validated by transcripts — kept on plan, watch for client pushback
- Network admin in current static demo could mislead Mahinder/Nisha about Phase 1 scope
- Trade booking flow not yet in the static demo — needs verbal walkthrough at the call
- Chinmay's React availability is unconfirmed (build plan does not depend on him)
- Mahinder remains a relay, not a champion — no plan B for buyer access yet
🔧 What needs correction / decision
- Need explicit answer: is Nisha the builder or her employer? (§2.1)
- Need explicit answer: same Nisha as the previous osTicket build? (§2.2)
- Need date commitment for Mahinder demo before we can sign-off Phase 1 start
- Static demo's network-admin/supervisor labels may need to be hidden before client view
- This HTML doc should be hosted on a real URL (GitHub Pages or VPS) so it's shareable
Documents map
| File | Purpose | Audience |
|---|---|---|
docs/docs.html | This page — visual, shareable, single file | Ash + Client |
docs/PRODUCT_PLAN.md | Full 1,656-line product plan (18 sections) | Ash + engineers |
docs/ARCHITECTURE.md | Visual board with Mermaid diagrams | Engineers |
docs/AUDIT.md | Transcripts × demo × starter-kit gap analysis | Ash |
docs/HANDOFF.md | Canonical scope reframe from the repo | Ash + engineers |
docs/COMPETITOR_RESEARCH.md | Existing AU/global construction platforms and positioning lessons | Ash + sales |
docs/VPS_REUSE_AUDIT.md | Which old VPS projects can be reused safely, and what must stay new | Ash + engineers |
CLAUDE.md ↔ AGENT.md | Agent onboarding (symlink, single source of truth) | Claude Code + Codex |
index.html, app.js, styles.css | The static clickable demo (do not touch) | Client demo |