Product architecture · v0.20 · July 2026

One workspace for the whole wedding

Source → Plan → Execute → Settle. Built for multi-event Indian weddings first — many events, two funding families, deep ceremony logic — and architected so any culture is just another template pack. The planner holds the admin seat; every other party gets a small, beautiful, role-scoped surface.

Sourcevenues · preferred lists · RFQs

Planevents · guests · budget · decisions

Executerun sheets · photo groups · day-of

Settlepayments · deliverables · reviews

Architecture map

How the modules connect. Fill and stroke encode the build order — solid maroon ships in v1, gold outline in v1.5, dashed in v2+. The Core Workspace is the spine; Decisions and Comms span everything as horizontal layers.

v1 v1.5 v2+ flywheel

Tenancy: who logs into what. The system is multi-tenant at the planner level. Vendors are logged to the planner's studio, not to a single wedding — use a vendor once and they're in the roster forever, with history. Each layer below is a distinct login scope.

Level	Who	Contains
Planner Studio	Planner + staff	All wedding clients in one dashboard. The vendor roster: every vendor ever used, auto-logged from past weddings ("used on 6 weddings · last Nov 2025"), with preferred / approved / backup flags and private notes. This roster is the planner's accruing IP.
Wedding Workspace	Couple + families	Their wedding only: events, decisions, budget (scoped by funder), guests, timeline. The couple's portal is this workspace with the admin seat hidden or held, depending on mode.
Engagement	Vendor × wedding	What a vendor sees for one wedding: their quotes, contracts, briefs, POC details, call times, payment status. Vendors upload and share contracts and details here — nothing outside their engagement is queryable (enforced by RLS).
Vendor Account	Vendor, global	One login across all planners and weddings. Profile, POC, standard docs (insurance, W-9) uploaded once and reused per engagement. Adding a vendor to any wedding creates or updates the roster entry automatically.

Roles: capabilities per module, not user tiers. Six capability levels (view → comment → edit → approve → sign → admin) assignable per module or per object. Roles are pre-bundled for the invite flow — no checkbox maze — and the planner can preview "view as" before inviting anyone.

Role	Typical person	Bundle
Admin	Planner (or couple in self-plan mode)	Everything. Exactly one admin seat per wedding.
Staff	Planner's associate	Edit all modules; financials optionally hidden; cannot sign.
Couple	Bride & groom	Sign decisions, edit guests, view everything, delegate.
Family voice	Parents / funders per side	Approve & pay their side's budget lines; comment anywhere; other side's numbers invisible.
Event lead	Sibling running the sangeet	Full edit on assigned events only; view the rest; no budget.
Observer	Grandparents, extended family	View + comment. Defuses "why can't I see anything" without handing over edit rights.
Vendor / Guest	Per engagement / household	As per tenancy above — scoped surfaces, not workspace roles.

Modules

#	Module	Stage	Owns	Phase
01	Core Workspace	All	Wedding container; events (haldi, sangeet, ceremony, reception, pujas…); parties with roles & permissions. Everything hangs off this.	v1
02	Traditions Engine	Plan	Template packs by community (Tamil Brahmin, Telugu, Punjabi Sikh, Gujarati, fusion). Generates event structure, ritual checklists, timeline recs, song & shot seeds. A generator, not a screen.	v1
03	Sourcing	Source	Vendor discovery; the planner's vendor roster — auto-logged from every wedding, tiered preferred / approved / backup, with usage history and private notes (the planner's IP); RFQ flow with side-by-side quote compare; venue search.	v1 lite
04	Planning & Decisions	Plan	Tasks & timelines. Decision log: proposed → discussed → approved, timestamped with full audit trail. E-signature sign-off via email on finalized plans, contracts, and briefs — signed versions locked and versioned. Issues: anything off-track, tagged to any object (event, vendor, decision, budget line), assignable with due dates — surfaces wherever the tagged object appears.	v1
05	Guests & RSVP	Plan	Households as the unit; per-event invite matrix (ceremony yes, reception no); RSVPs, meals, headcounts rolling up per event.	v1
06	Guest Hub	Plan / Execute	Guest-facing site: schedule, dress codes per event, maps. Travel & accommodation: hotel blocks, out-of-town tracking, shuttles.	v2
07	Vendors + Briefs	All	Quote → contract → invoice → payment lifecycle; scoped vendor portal. Invoices are structured objects (line items, event attribution, due dates, attached PDF) flowing straight into Budget actuals. Payments: milestone schedules (deposit / progress / final) per contract; pay through platform (Stripe Connect, ACH-first) or record as paid off-platform — full ledger either way. Funder-routed requests: each payment request goes to the family funding that budget line. Structured, sign-off-able Vendor Briefs (table below).	v1.5
08	Budget	Plan / Settle	Lines by event with funder attribution (bride's side / groom's side / couple). Accepted quote = planned; invoice = actual; over/under rolls up live.	v1.5
09	Day-of Execution	Execute	Run sheets per event; vendor call times; photo groupings from the real RSVP list, auto-notified; seating; live change channel.	v2
10	Settle	Settle	Final payment reconciliation; deliverable tracking (photo/video dates, album approvals); gift & shagun log; vendor reviews → back into Sourcing.	v2.5
11	Comms	All	Announcements & messaging scoped by role and event — lives inside every module, not a separate inbox.	v2
12	Muhurat Finder	Pre-Source	Decision zero, before a planner is even hired — top-of-funnel. Inputs: community & calendar system (Amanta / Purnimanta / Tamil solar / Nanakshahi), wedding city (panchang timings are location-dependent), date window, optional birth details (Ashtakoot for North Indian, Dashkoota for South Indian matching). Output: ranked dates with muhurat windows, plain-language why / why-not (kharmas, combust periods), venue cross-check, exportable shortlist for the family panditji — never a verdict. Sikh mode switches to gurdwara availability (no muhurat). Chosen date anchors the wedding; muhurtham time flows into the ceremony run sheet. Built on an astrology API (ProKerala / DivineAPI class), not in-house computation.	v2
13	Notifications	All	Digest-first, role-scoped: event-driven alerts only to affected parties (signatures, payments T-7/T-3/day, brief revisions, call-time changes); digests per role (planner morning brief, couple weekly, families only-when-routed); escalation ladder in-app → email → WhatsApp/SMS if urgent + unread. WhatsApp Business API as a first-class channel; per-user language & timezone quiet hours; hard cap of 4 lifetime messages per guest.	v1.5+

Vendor Briefs

Shot lists and song lists are the same object: a versioned, structured brief attached to a vendor + event, visible in that vendor's portal, confirmed with a timestamped sign-off. Briefs flow planner → vendor; info requests flow vendor → planner. One two-way pattern extends to every vendor type without new code.

Brief	Vendor	Contents
Shot list	Photographer / video	Must-have shots; photo groupings pulled by name from the RSVP list; ritual moments flagged from the Traditions pack.
Song list	DJ	Recommendations by language (Tamil, Hindi, Punjabi, Telugu…) seeded from the Traditions pack; must-play; do-not-play; key moments (baraat entry, first dance).
Menu brief	Caterer	Per-event menus; dietary counts pulled live from RSVP data.
Decor brief	Decorator	Moodboards, per-event themes, mandap specs.
Info request	Any vendor	Runs the other direction — planner requests structured fields, vendor fills them in their portal: day-of contact name & phone, arrival/setup time, crew size, power & space needs, COI. Day-of contact and arrival time flow automatically into the run sheet and call times.

Color palette candidates

Direction: ceremonial warmth with software discipline — rich cultural color used sparingly against calm neutrals, so the product reads premium to a bride and credible to a planner running forty vendors. Each palette shown with live component mocks. This document itself is set in Palette 01.

01 · Sindoor & Silk

Recommended

Deep sindoor maroon and zari gold on silk ivory. Ceremonial gravity without loudness — reads bridal to families, serious to planners. Gold is reserved for accents and money.

#F6F1E7silk ivory · bg

#FFFFFFsurface

#7A1B12sindoor · primary

#B08A2Ezari gold · accent

#211A16ink · text

SIGNED · JUL 20

Sangeet · Aug 14212 confirmed · 3 vendors on site

02 · Marigold & Peacock

Festive modern

Peacock teal as the working color, marigold as celebration. Fresher and younger than 01 — strongest fit if self-planning couples become the lead audience. Risk: teal reads less distinctly "wedding."

#FBF6EChaldi cream · bg

#FFFFFFsurface

#1F5F5Bpeacock · primary

#E8A020marigold · accent

#1C2321ink · text

SIGNED · JUL 20

Sangeet · Aug 14212 confirmed · 3 vendors on site

03 · Rani & Aubergine

Editorial bridal

Rani pink against deep aubergine and brass — the most fashion-forward of the three, closest to a bridal magazine. Beautiful for marketing and the Guest Hub; hardest to keep calm across dense planner screens.

#FAF4F0blush ivory · bg

#FFFFFFsurface

#A62B58rani · primary

#3B2138aubergine · deep

#A98548brass · accent

SIGNED · JUL 20

Sangeet · Aug 14212 confirmed · 3 vendors on site

A workable hybrid: ship the planner workspace in 01 and let the Guest Hub theme per wedding (couples pick their event palette) — the tool stays disciplined while every wedding's public face feels like theirs.

Theming is a product feature, not a launch decision. Three layers: (1) a product default we ship; (2) a planner studio theme — each planner picks from a curated set (or their brand colors), so their clients experience their branded system, white-labeling lite and a real selling point for premium planners; (3) the per-wedding Guest Hub theme the couple picks. All three are the same mechanism — design tokens (palette, type pair, radius, motif) swapped per tenant, which the theme explorer below demonstrates live. Curated themes only in v1; freeform brand colors later.

→ Theme Explorer: the planner home in the current baseline plus seven modern-Indian directions (Pink City Modern, Indigo Khadi, Charcoal & Genda, Haldi New Wave, Ivory Editorial, Bombay Deco, Terracotta Craft), switchable live.

Build plan

Sequence and scope are firm; calendar durations are working estimates and depend on staffing — treat them as relative sizing, not commitments. Each phase has a hard exit criterion: a real-world event that proves the phase, not a feature checklist.

Phase	Ships	Effort	Exit criterion
v1	Core Workspace · Traditions Engine (3–4 packs) · Planning & Decisions incl. audit trail + native e-sign · Guests & RSVP · Sourcing-lite (preferred lists + quote compare)	~8–10 wks	One real planner running one live wedding in it, start to finish of the planning phase.
v1.5	Vendors full lifecycle + scoped portal · Vendor Briefs (shot list, song list, menu, decor) · Budget with funder attribution	~4–6 wks	A vendor submits a quote, signs a brief, and tracks payment status entirely through their portal — no email thread.
v2	Guest Hub with per-wedding theming · Day-of Execution (run sheets, photo groups, seating, live changes) · Comms	~6–8 wks	A wedding weekend executed off the run sheet, with photo groups called from the app.
v2.5	Settle — reconciliation, deliverable tracking, gift/shagun log, vendor reviews	~3–4 wks	First post-wedding review lands on a planner's preferred list. Flywheel turns once.

Stack. The multi-party permission model is the whole product, so it's enforced at the database layer, not in app code.

Layer	Choice	Why
Database + auth	Supabase (Postgres, Auth, RLS)	Row-level security maps 1:1 onto role-scoped surfaces — a vendor literally cannot query rows outside their own quotes and briefs. Auth handles planner / couple / family / vendor / guest roles.
App	Next.js on Cloudflare Workers	Guest-facing pages (RSVP, Guest Hub) are edge-cacheable and fast on any phone. Fall back to Fly.io (DFW) if Workers runtime limits bite on the planner app.
Files	Cloudflare R2	Signed contracts, brief PDFs, photo deliverables. Signed documents stored immutably with a content hash alongside the e-sign record.
Email	Cloudflare Email Routing + transactional sender	RSVP invites, e-sign links, vendor notifications. E-sign v1 is native: emailed link → typed signature → timestamp + document hash. DocuSign-grade integration deferred to vendor contracts if needed.
Payments	Stripe Connect · ACH-first	Vendors onboard as connected accounts (Stripe handles KYC + payouts); the platform never holds funds — no money-transmitter licensing. ACH default because wedding amounts are large (2.9% card fees on a $23k catering bill is real money); cards as fallback. Application fee per transaction = future revenue line. Off-platform payments (Zelle, check) still recorded, so the ledger is complete even when the money moves elsewhere.
Repo / dev	GitHub · Claude Code (desktop)	Single monorepo; template packs (traditions, song/shot seeds) live as versioned data files, not code.

Mockups

Clickable prototypes, all in Palette 01 with realistic fake data (Priya & Arjun — a 428-guest Tamil–Punjabi fusion wedding). Links are relative: they resolve when these files sit together in the repo / on Pages.

#	Prototype	Seat	Shows	Status
01	Planner Studio + Wedding Workspace	Planner	Multi-wedding dashboard; auto-logged vendor roster with tiers & private notes; wedding workspace tabs (events w/ ritual tags, decision log with live send-for-signature flow, issue tracker (add + tag to events/vendors/decisions), guest invite matrix, vendor engagements, budget with funder attribution).	BUILT
02	Couple Portal	Bride & groom	Same wedding, softer seat: "needs you two" queue with typed e-signature flow (mirrors the planner's request in 01), baraat preference picker, weekend schedule with dress codes, decision record, RSVP pulse, money by funder.	BUILT
03	Vendor Portal	Vendor	DJ Dhol Nation's single engagement: status strip, song-list brief with typed confirmation (languages, must-play, do-not-play), info request form whose fields flow into the run sheet, call times, milestone payments with invoice upload.	BUILT
04	Guest RSVP	Guest	Phone-first household RSVP: the Gill family across their three invited events, per-person toggles, reception meal choices, room-block info, one submit.	BUILT
05	Family / Funder Seat	Bride's side	Mr. Venkataraman's view: funder-routed payment request (pay by ACH or record off-platform), family voice on the floral decision, bride's-side budget lines only, their guest counts.	BUILT
06	Guest Hub	Public	The wedding's public site — schedule, dress codes, travel, FAQ, RSVP link. Deliberately themed in Palette 03 (Rani & Aubergine) to demonstrate per-wedding theming while the tool stays in 01.	BUILT
07	Day-of Run Sheet	Planner	Live Sangeet timeline: mark-done steps, DJ contact pulled from the info request, photo groups built from RSVP with one-tap notify, and a "shift +15 min" delay button that re-times the night and pings affected vendors.	BUILT
08	Sourcing / RFQ Compare	Planner	One brief, three quotes side by side — roster vendor with the planner's private note vs. two new vendors; accepting a quote creates the budget line, opens the engagement, and logs the decision. Over-budget quote flags the funder first.	BUILT
09	Traditions Onboarding	Planner	Pick template packs (Telugu, Tamil Brahmin, Punjabi Sikh, Gujarati) and watch the wedding assemble live — events, ritual counts, fusion merge logic — then create the workspace from it.	BUILT
10	People & Roles	Planner	Members list with real role spread (staff, event lead, family voice, observer); invite flow with pre-bundled roles, live per-module capability grid, and "view as" preview before sending.	BUILT
11	Muhurat Finder	Couple / family	Community-aware date finder: calendar-system notes per tradition, ranked dates with muhurat windows and why/why-not (kharmas shown as considered, not missed), venue cross-check, WhatsApp shortlist export to the panditji. Sikh mode switches to gurdwara availability.	BUILT
12	Notifications	All	Needs-action inbox vs digests (planner morning brief, couple weekly, guests capped at 4 lifetime messages); channel preferences with WhatsApp preview, per-person language and timezone quiet hours, escalation ladder.	BUILT
13	Outfits & Trousseau	Couple	Every look attached to its event — heirloom kanjivaram to reception gown — with jewelry, tailor status flow (tap to advance), rentals, and the next fitting on the calendar.	BUILT
14	Theme Explorer	Planner (feature: studio theming)	The planner home in eight switchable skins — current baseline plus seven modern-Indian directions. Demonstrates the token-swap mechanism behind planner studio theming and per-wedding Guest Hub theming.	BUILT
15	New Wedding Wizard	Planner / couple	Step 1 of onboarding: couple, admin-seat mode (planner-led vs self-plan with live explainer), dates with a hand-off into the Muhurat Finder, funding sides. Step 2 is prototype 09.	BUILT
16	Self-Plan Home	Couple (admin)	The couple holding the admin seat — this-week queue, status board, and the "invite a planner" handoff card: the growth loop, on screen.	BUILT
17	Settle	Planner / couple	The fourth stage: final reconciliation, deliverable tracking, shagun & thank-you log, and a vendor review that visibly lands on the roster — the flywheel turning.	BUILT
18	Brief Builder	Planner	Composing the shot list prototype 03 receives: ritual moments from traditions packs, photo groups from RSVP, couple must-haves, send-for-confirmation versioning.	BUILT
19	Vendor Quote Submission	Vendor	Answering an RFQ against a fixed scope — line items, comparison flags — with W-9/COI riding along from the global vendor account. Feeds prototype 08.	BUILT
20	Change Order	All parties	Locked scope + delta + computed budget impact + a signature chain that includes the funder because it's his line. The #1 planner-client fight, retired.	BUILT
21	Comms Composer	Planner	Announcement scoped by role × event with a live reach preview before send, guest-cap accounting, and auto-pinning to the Guest Hub.	BUILT
22	Seating	Planner	Households (never individuals) tapped from the live RSVP pool into tables with capacity math — same data that powers photo groups.	BUILT
23	Data Model	Co-founder / build	Site tab: 24 entities in four domains, key relationships, and RLS-per-seat in one sentence each — derived from every mockup above, destined to become Supabase migration 0001.	BUILT

Backlog — future-proofing

Real pain points the object model should anticipate now, even where the feature ships later. Mostly these are existing objects pointed at new problems.

Feature	For	What it is
Vendor date-conflict detection	Planner	The roster knows a vendor is booked on another client's date — warn before the RFQ goes out. Only possible because the roster spans weddings.
Change orders	Planner ↔ all	Scope changed after signing → delta documented → budget updated → re-signed. The #1 planner-client fight, solved by the decision log pointed at money.
Guest quotas per side	Families	Each side gets N invites, tracked live against the matrix. The politics manager.
Visa invitation letters	Families	Generator for relatives traveling from India + travel status per household.
Livestream hub	Guests abroad	Per-event stream links on the Guest Hub for relatives who can't fly.
Guest photo uploads	Everyone	Post-event shared gallery; guests contribute, couple curates.
Multi-language UI	Parents' generation	Per-user language across the product — Hindi, Tamil, Telugu, Gujarati, Punjabi first.
Legal paperwork checklist	Couple	Marriage license, officiant filing, post-wedding name-change steps — jurisdiction-aware.

Open questions

E-signature depth. Native lightweight sign-off (email link + typed signature + timestamp) for internal approvals, with a DocuSign-grade integration later for vendor contracts — or legal-grade from day one?
Sourcing in self-plan mode. Do planner-free couples get marketplace-style discovery in v1, or is sourcing planner-mode-only until the review flywheel has data?
Recommendation engine. Song and shot recs seeded as static content per Traditions pack in v1, or AI-generated per wedding from day one?
Palette. 01, 02, 03 — or the hybrid (01 for the workspace, per-wedding theming for the Guest Hub)?
Monetization. SaaS-only (planner subscription), or SaaS + a take rate on platform-processed payment volume? The Stripe Connect rails make the second possible — the HoneyBook/Toast playbook. Decide before pricing conversations with planners.

WEDDING PLATFORM · MODULE MAP v0.20BUILD LOG →SOURCE → PLAN → EXECUTE → SETTLE