Marriage ecosystem: does the loop hold?

Assessed 2026-09-28 at the owner's request. The question: can Marriage Biodata be the entry point into a shareable Consumer + Merchant ecosystem, and what must be built into the MVP now so that the marketplace grows by sharing rather than by acquisition?

Inputs. Claude Design's assessment, pulled fresh the same day from prototype/review/MarriageEcosystem.dc.html in the project "QR setu prototype". Read-only SQL against qr-setu-dev (dyhjofjjuazhyqcvlrkx). Four read-only repo audits covering merchant backend, consumer and sharing, media and web, and strategy and capacity; their load-bearing claims were re-read before use.

Part of Strategy; the evidence tags 📘 🧮 🌐 🔎 ❓ follow the legend there. Findings are logged as QRS-1440 to QRS-1449.

The verdict, in four sentences

Yes, the ecosystem makes sense for QR setu, but not on the loop as drawn. Its first arrow, Biodata → Merchant Discovery, is forbidden by the owner's own firmest consumer rule 📘, and it would not work if it were allowed 🔎. The loop that compounds is anchored on the merchant's share: a store or studio replaces the twenty WhatsApp photos it already sends with one link that carries its name, and the family forwards that link for it. The backend supports the goods half of this today and almost none of the expertise and time half 🧮, and production does not exist yet 🧮, so an end-of-November launch of five categories is only feasible as a narrower first step than either Claude Design or the brief proposes.

0 · The key product question, answered

The hypothesis, tested arrow by arrow

Marriage Biodata → Consumer Sharing → Discovery → Merchant Discovery → Merchant Setu Card → Collections/Portfolio → Shortlist/Request → Interaction → Sharing → More Consumers/Merchants

Arrow	Holds?	Why
Biodata → Consumer sharing	✅ Yes	🧮 Built on Dev: a forwardable tokenless link (/:slug/biodata), a WhatsApp link preview with no face, and a "Make yours free on QR setu" growth card. It is a real consumer→consumer loop.
Consumer sharing → Discovery	⚠ Only of QR setu, not of merchants	🔎 A biodata recipient is a family weighing a match, months before any wedding, and most biodatas never lead to one. They discover the brand, and at best make their own biodata.
Discovery → Merchant discovery	⛔ No, by decision	📘 marketplace-relationship §3, the owner, 2026-08-28: a biodata is "not part of the marketplace and never should be". Surfacing wedding vendors when a proposal is finalised was withdrawn. The design brief carries the same rule (consumer-context-prompt.md:306-308). Claude Design's "binding direction" is our own rule echoed back.
Merchant card → Collections/Portfolio	⚠ Goods yes, expertise no	🧮 Items with up to 8 photos render on the public card. There is no album, no video and no portfolio block, and an on_enquiry item shows no action (QRS-1441).
→ Shortlist/Request	❌ Absent	🧮 No saved, list, lead, enquiry or booking table exists on Dev.
→ Interaction → Sharing → More users	❌ Unmeasurable	🧮 No event store and no ref on any link (QRS-1444). A loop nobody can count cannot be tuned, priced or proved to a merchant.

The loop that does compound

The sharer has to be the person who benefits from sharing. There are three such people, in order of how soon they exist:

1. The merchant. 🔎 They already send photo dumps and price images on WhatsApp all day in season. A link that replaces that dump saves them time, and every forward of it carries their store's name. Distribution is paid for by the merchant's own self-interest.
2. The family. 🔎 A wedding decision is made by four to eight relatives, and some of them are not in Pune. One list they can all open and react to in a browser, with no install, is better than three scattered chats. Each open is a first look at QR setu.
3. The other vendors. 📘 The strategy pages already rank merchant-to-merchant as the strongest loop available (virality-and-adoption, revalidation §11). Wedding vendors work the same weddings and refer each other. A mutual "worked with" credit on a card is how the trade already finds work.

What the biodata legitimately gives the merchant side 🔎: consumers who already hold an account with an address (every account gets a slug at creation, 📘 ADR-0032). It also gives brand trust among families, and a consumer population that later browses the marketplace as ordinary buyers. That is how the relationship is framed in marketplace-relationship §2. It is valuable and indirect, and it must never become a targeting input.

Directory or ecosystem?

It becomes a directory if discovery is the first thing built. 📘 The in-app marketplace is off for R1 (consumer/decisions.md:21), and the strategy pages rank it "lowest now". Both are right: browse needs supply density per category per city, which no share-less directory has ever acquired cheaply. The marketplace should emerge as the index of what is already being shared, first as the SEO category-city pages that already exist (/marketplace/:category/:city, 🧮 built) and in-app browse last.

1 · Claude Design's vision, summarised

📘 Read from the design's own data, fresh on 2026-09-28.

• Verdict it reached. Wedding trades are not covered: bridal wear exists only as a generic boutique with a cart, and (in the prototype) boutique and photographer onboarding fall through to the Ganapati stall console. Three shared pieces are missing: a shortlist you can share, a request that carries the items picked, and dates as inventory. Build them once, and six trades become data entries.
• The boundary it drew. The biodata is sealed. The family enters the vendor side only through doors it opens itself: a vendor's QR, a shortlist a relative forwards, and an invitation where the family may credit its vendors.
• Bridal and groom wear. Conversion is by visit, not cart. The journey runs: scan the shop QR → occasion collections → look page → shortlist → share with family (keep or skip) → request a trial visit with the shortlist attached → hold → order tracker → pickup with the code → review. Groom wear is a different workflow: rental, group orders for the baraat, and on-day safa tying.
• Photographers. Dates are the inventory. The card shows "Check your date", albums by style, films linked rather than uploaded, packages with included and extra declared, and a reference brief (up to ten frames plus events). After the wedding, the family picks album frames with the same tool reversed.
• Other trades. Makeup, mehendi, jewellers, tailors and purohits by configuration. Venues, caterers, decorators and planners later. Invitation printers as partners. Transport and sweets folded into existing trades. Marriage bureaus excluded.
• Sixteen reusable modules, among them: Shortlist (the keystone), Structured request, Date availability, Quote, Hold, Rental, Albums, Order stages, Measurement profile.
• One modelling change. Stop letting shape choose the button. Add conversion (order · visit · book · enquire) and inventory (stock · slot · date · none) to the industry record. It proposes twelve industry configuration fields in all.
• Phasing. Design fixes in October → a two-trade MVP piloted in December with about ten Pune businesses, live for January → close-the-sale features before April and May → after-the-wedding features in the second half of 2027. Never: bridal checkout, vendor suggestions from a biodata, commission, a wedding app per trade.
• Fourteen design gaps, two of them "Critical", and seven decisions it asks the owner for.

Where Claude Design is right, and this page agrees: the sealed biodata; conversion by visit for bridal; dates as the photographer's inventory; the vendor-credit loop; no trade-specific screens; seasonality breaking the 90-day inactivity rule; the December pilot rather than a November launch.

Where it is wrong or incomplete: it read its own prototype JavaScript, never our backend. Eleven of its facts are wrong about what exists (§4), it misses the two dependencies that block everything (§6), and its MVP holds two platform-sized capabilities the backend has no substrate for (§8).

2 · Consumer-side capability assessment

Capability	State on Dev	Evidence	Class
Create, publish, forward a biodata	✅ Built (Dev and devv; not Prod)	🧮 biodata.* schema, manage-biodata, biodata-read; routes /:slug/biodata and /:slug/biodata/:share	S
Link preview on WhatsApp	✅ Built	🧮 Static themed PNG with no face; noindex, no-store (QRS-1255)	S
Growth card on the public page	✅ Built, unmeasured	🧮 Links to a bare https://qrsetu.com (BiodataPage.tsx:84)	S → M to add ref
Recipient keeps a profile	⚠ Backend only	🧮 biodata.kept + EF action exist; zero UI callers; no read RPC	M
Anonymous reading	✅	🧮 No session gate on consumer routes; discovery RPCs are anon-callable	S
Anonymous identity (device)	❌	🧮 No anonymous sign-in, device id or installation id anywhere	B
Sign-in	✅ WhatsApp OTP, Google fallback, never email (D8)	📘 consumer/decisions.md D8	S
Every account has an address	✅	🧮 slugs registry, 24 rows on Dev; ADR-0032	S
Chat consumer↔merchant	⚠ Backend built, in-app thread route missing	🧮 manage-chat bound to Supabase; QRS-1089	M
Saved items, lists, shortlists	❌	🧮 "there is no saved table in any schema" (get_my_consumer_activity)	P
Invitation, birthday card, photo album QR	❌ Design only, owner-deferred	📘 QRS-1091; 🧮 no table, EF or route	B (new bounded context)
Wi-Fi and link QR makers	✅ Client-only	🧮 BUILT_MAKERS = ['wifi','link']	S
Marketplace browse and item feeds	✅ RPCs built, ⛔ off for R1	🧮 get_consumer_item_feed, get_consumer_vendor_feed; 📘 decisions.md:21	F
Inbound deep link (WhatsApp → app)	❌	📘 QRS-1360; marketplace-relationship measured intentFilters: null	B
Share attribution	❌	🧮 QRS-1444	P

Consumer-side reading. The consumer half is strongest exactly where the merchant loop will land: an anonymous, no-install, server-rendered web page with a good WhatsApp preview and a growth footer. The biodata's public page is the template for every share page the merchant loop needs 🧮: token in the path, noindex for token links, the OG script, rate limits, the growth card. Its code is not reusable as-is, because it lives inside the biodata bounded context by decision (D7, ADR-0031). The pattern is reusable.

3 · Merchant-side capability assessment

Capability	State on Dev	Evidence	Class
Industry registry, archetype, primitives, grants	✅ Live	🧮 14 industries, 3 archetypes, 11 primitives, 24 features, 57 grants	S
boutique, salon, photographer industries	✅ Rows exist	🧮 all public; item_attribute_schema is NULL for all 14	S / M
Bridal wear, jeweller, makeup, mehendi, tailor, purohit rows	❌	🧮 absent	M (one data migration)
Onboarding from the registry, no silent fallback	✅	🧮 provision_merchant_workspace raises for an unknown industry; IndustryStep reads get_industries()	S
Onboarding promises	❌ False for photographer and boutique	🧮 QRS-1443	M
Catalogue items (kinds incl. package, service; units incl. session, day)	✅	🧮 catalog_items_kind_check, _unit_check	S
One-of-a-kind item	✅	🧮 is_unique + catalog_item_claimed() hide a claimed piece from the public card	S
Price on enquiry, withheld server-side	✅ Read side; ❌ no writer	🧮 get_public_catalogue nulls the price; manage-item has no pricing_mode (QRS-1441)	M
Price band ("from ₹40,000")	❌	🧮 pricing_mode is fixed or on_enquiry only	B
Occasion collections (categories)	❌ No writer	🧮 0 categories on Dev; nothing inserts one (QRS-1447)	M
Facets (fabric, work, occasion) in attributes	⚠ Storable, not shown on the card	🧮 get_public_catalogue does not project attributes; the consumer feed already facets them	M
Item photos	✅ Web console only; ❌ mobile	🧮 8 per item; public R2 bucket; itemPhotoPicker has no caller (QRS-652)	M
Logo, cover, OG image	❌ No client	🧮 QRS-1442	M
Albums, video, film links	❌	🧮 images only (jpeg/png/webp/avif, 10 MB); links only as setu_card_links	P
Publish the card	✅ Web console; ❌ mobile writes to a stub	🧮 QRS-816	M
Per-item public page with its own preview	❌	🧮 no route; catalog_items.slug exists	M
Orders from the public card, Razorpay link, status page	✅ Built, dark in production	🧮 place-public-order, get_public_order_status	S
Advance or token payment	❌	🧮 advance_pct / advance_terms unread; the link charges the full subtotal	B (money path)
Pickup order code	❌ Stub contract	🧮 packages/data/src/collection/service.ts:12-13	B
Leads, enquiries, party records	❌	🧮 no table; customers feature registered with nothing behind it	P
Bookings, slots, dates, capacity	❌	🧮 no table; bookings feature registered with nothing behind it	P
Holds	⚠ resource_holds: exclusive, minutes-grained, called by nothing	🧮	B for a multi-day hold
Reviews, ratings	❌	🧮 no table (QRS-576)	P
Merchant analytics	❌ Stub	🧮 setuCardActivity stub; no event store	P
Chat, quick replies, reminders	✅	🧮 bound seams, live EFs	S

Merchant-side reading. 📘 revalidation's August headline still holds on today's Dev 🧮: "the platform has built the substrate for one archetype and designed the strategy for the other two." Bridal wear and jewellery are goods: they can be listed, shown, shared and ordered today. Photographers, makeup artists and mehendi artists are expertise and time. Their card produces an enquiry or a booking, and nothing on the platform can store either.

4 · Backend architecture fitment

The platform model fits; its middle layer is empty

🔎 Industry × archetype × primitives × grants is the right shape for "a new vertical is configuration". Each wedding trade is one industries row: an archetype, a primitive composition, an attribute schema and a marketplace slug. The configuration layer that would make a bridal store different from a kirana is present and empty. The attribute schema is NULL everywhere, no resolver reads it, the public card does not project attributes, and the only facet vocabulary in code is the hardcoded Ganapati one (packages/domain/src/catalog/ganapatiFacets.ts). Filling that layer is the cheapest high-value work on this page.

Claude Design's modelling change is half right. The button is chosen by shape: primaryCta() maps goods → order, time → book (which is the same pay-order path), expertise → nothing (🧮 cta.ts:44-50). Archetype is our word for shape. A conversion field on the industry record, with one resolver deriving the card's primary action, is the correct fix and a small one. Its inventory axis should wait: its only new value is date, and nothing can store a date until Step 4 (§15). Adding a column with no reader is how this schema acquired its empty bookings feature.

Where Claude Design's facts are wrong (QRS-1448)

#	Claude Design says	The backend says	Consequence
1	Leads pipeline Exists, "fits every wedding trade unchanged"	🧮 No leads, enquiry or party table. 📘 A lead entity is "explicitly FUTURE" (marketplace-relationship), yet QRS-668 decided an enquiry form	The "structured request" is a new platform capability, not an extension, and it needs a decision (D-B)
2	Bookings "works for time businesses"	🧮 No bookings, schedule or slot table; "Book" is the pay-order path	"Trial visit" and "staff prep list" have no substrate
3	Reviews and reputation Exists	🧮 No reviews table (QRS-576)	"Review earned by the order" is new work
4	Order code handover "fits as it is"	🧮 Stub contract, no table, no EF	Pickup-with-code is new work
5	Payments Exists for "advance, token and balance"	🧮 Full-subtotal payment link only; advance_pct unread; payments dark in production	Date-blocking advances are money-path work
6	Invitations and a photo album QR Exist on the consumer side	📘 Deferred by the owner (QRS-1091); 🧮 nothing built	The "invitation door" into the ecosystem does not exist
7	Saving needs "an email code"	📘 D8 bans email; 🧮 there is no saved store at all	The shortlist is new, not a relaxation of a gate
8	Price bands "through the existing from price kind"	🧮 pricing_mode ∈	A price band is a schema change
9	Boutique and photographer have no industry record, fall back to festival stall (Critical)	🧮 Both rows exist; unknown industries raise, never fall back	The prototype defect is real in the prototype only. The real onboarding defect is false promises (QRS-1443)
10	No one-of-a-kind state	🧮 is_unique + catalog_item_claimed()	Already supported
11	Hold is a New module	🧮 resource_holds exists but is payment-race shaped (minutes, exclusive, unused)	Reuse the idea; a multi-day piece hold is a different contract and should not overload it

The dependencies Claude Design did not see

1. Production does not exist. 🧮 Prod has no v2 schema, so every card URL returns 500 (QRS-776). Release 26.0.1 is scoped with 174 Change Records, 0 builds and 0 approvals, and has never been promoted (production-state). Nothing on this page reaches a single merchant until that promotion happens.
2. A shared card is not visual yet. 🧮 Mobile merchants cannot add item photos (QRS-652) and no client can set a logo, cover or preview image (QRS-1442). For the categories chosen because they are visual, the unfurl is the product.
3. Nothing is measurable 🧮 (QRS-1444). The design's own §11 metrics ("share opens per shortlist", "calls avoided") have no store to be computed from.
4. The G-D gate. 📘 check:release refuses a vertical: scope item without an approved verticals/<slug>/discovery.md (QRS-475). No wedding trade has one, and no merchant in any of them has been interviewed. Separately, the taxonomy's own "only discovered industries are public" rule is not honoured (QRS-1445).

5 · Existing capabilities we can reuse

Reuse	For	Evidence
Industry registry + marketplace_slug + get_industries()	Five new categories as five rows, and their SEO category pages	🧮 live
catalog_items kinds package / service, units session / day, attributes jsonb	Photographer packages, makeup trials, bridal looks with facets	🧮 constraints read on Dev
is_unique + catalog_item_claimed()	One-of-a-kind bridal pieces that leave the card once sold	🧮
Server-side price withholding (QRS-456)	Jewellery at the day's rate; "price on request" bridal	🧮 get_public_catalogue
Public R2 bucket, catalog_item_media (8 ordered photos)	Look pages and a first portfolio from item photos	📘 CR-26.0.1-75; 🧮
setu_card_links (http/https only)	Films and reels linked, never uploaded, exactly as the design wants	🧮
place-public-order, Razorpay link, status page	Goods orders; later an "advance" as a priced item (§8, with its failure mode)	🧮
Chat between principals, item messages, media messages	"Ask about this look" once the in-app thread route exists	🧮
Biodata's share pattern: hashed token, expiry, withdrawal, opens, OG, noindex, growth card	The template for selection pages	🧮 biodata.shares
rate_limits + consume_rate_limit	Anonymous keep/skip and anonymous requests	🧮
Reminders (rule + sparse occurrences)	Merchant follow-ups and the family's own reminders	🧮
Marketplace RPCs and /marketplace/:category/:city	The SEO discovery door for "bridal wear in Pune" without the in-app marketplace	🧮 built; 📘 in-app off

6 · Missing backend, API and schema capabilities

Classified in the owner's vocabulary: S already supported · M minor extension · B new backend capability · P new reusable platform capability · F future-only.

Missing	Class	Size 🔎	Blocks
pricing_mode writer; category (occasion) writer; variant writer	M	1–2 d	Enquiry-priced looks, occasion collections
Industry rows (bridal wear, jeweller, makeup & mehendi) + attribute schemas + resolver	M	2–3 d	Everything category-specific
get_public_catalogue projects attributes	M	0.5–1 d	Facets on the card
conversion on industries + one primary-action resolver	M / B	1–2 d	The right button per trade
Per-item public read (by item slug)	M	1 d	Look pages
Public event write path (view, share-open, ask-click, order; no PII)	P	3–5 d	Every metric, the merchant's value report
Selections: an ordered set of references from one workspace, shareable by token, reactable anonymously	P	6–10 d + ADR	Send-looks, family keep/skip, albums
Party + request (the lead entity, typed brief, anonymous submission)	P	8–12 d + decision	Trial requests, photographer briefs
Schedule / date availability	P	8–12 d	"Check your date", date blocking
Advance or partial payment through the payment link	B (money path)	3–5 d	Date-blocking advances
Price band / "from" pricing	B	1–2 d	Bridal price ranges
Reviews	P	3–5 d (📘 H3 estimate)	Earned reviews
Invitations bounded context	B	weeks	The invitation door, vendor credits on invitations
Quote, rental, multi-day hold, order stages per industry, measurement profile	P / B	weeks each	Phase 2 and later

⚠ The sizes are my estimates 🔎. No estimate exists for any of them in the repo, and the last plan built on an assumed pace (1.5 days of output per calendar day, 26.0.1) slipped by weeks. Read them as relative size, not as dates.

7 · Missing product and UX capabilities

These need a design round before they are built (owner rule: the design-gap loop).

1. An action on an enquiry-priced item. Today it renders nothing (QRS-1441).
2. A look page: one item, full photos, facets, price or "on request", and its own link preview.
3. "Send these looks": the merchant picks items and sends one link to a customer's WhatsApp.
4. The selection view: a no-account page where relatives mark keep or skip, with the store's identity on it throughout and a growth footer for both sides.
5. A portfolio block on the card (an album of item photos first, film links beside it).
6. "Worked with": a mutual vendor credit between two published cards.
7. The merchant's share results: "your looks were opened N times by M people this week". The Analytics screen is built on a stub today.
8. The logo, cover and preview-image controls, on both merchant surfaces.
9. Corrected onboarding tiles for the categories, promising only what exists (QRS-1443, QRS-1424).
10. Later rounds: the request sheet and its inbox rendering; "Check your date" and the merchant's date calendar.

8 · MVP features Claude Design missed

#	Feature	Why it matters	Class
1	Share attribution from day one: a ref on every link and an append-only event write path	🔎 Without it no loop can be proved, tuned or sold. It is also the merchant's reason to pay: "this season your card brought 38 families". Failure mode: a view count is a vanity metric; the report must lead with asks and orders, not opens	P
2	Merchant-built selections before consumer-built ones	🔎 The design's keystone is the consumer's shortlist. The behaviour that already happens every day is the merchant sending photos. Same primitive; build the direction with zero adoption cost first	P (same primitive)
3	"Ask on WhatsApp about this" per item and per selection	🔎 Closes the no-action gap (QRS-1441) with no lead entity. The message carries the item name and link into the channel the merchant already works in, and the click is an event. It is the bridge until Step 3	M
4	Look pages with their own preview	🧮 No per-item URL exists. The atomic shareable unit of a visual trade is one look, not the whole card	M
5	A card that unfurls with an image	🧮 QRS-1442. It is the cheapest visual fix on the page	M
6	A growth footer that recruits both sides	🔎 Every share page shows "make your own list" to families and "get your free Setu Card" to the shop-owning relative, attributed to the share that recruited them	M
7	"Worked with" vendor credits in the MVP, not Phase 3	📘 The strongest loop the strategy found; 🔎 cheap: a typed link between two published slugs, shown only when both accept	M / B
8	SEO category-city pages for each new category	🧮 The route exists. "Bridal wear in Pune" is a door that needs no in-app marketplace	M
9	An advance as a priced catalogue item	🔎 e.g. "Makeup trial, ₹1,500" or "Reserve a shoot date, advance ₹10,000", through the existing order path. Failure mode: money taken for a date that is already taken forces a refund, so it is only safe after the merchant confirms the date in chat. Treat it as a pilot option, not a default	S (if payments are live)

9 · Features to defer explicitly

Defer	Until	Reason
Any link from biodata to vendors, or an inferred wedding date	Never	📘 owner rule, 2026-08-28
Invitations, photo album QR, guest photos, vendor credits on invitations	After a separate plan	📘 QRS-1091; 🔎 a new bounded context; highest reach, highest cost
Consumer marketplace browse in the app	Supply density per city and category	📘 off for R1
Quotes, rentals, group orders, safa tying, multi-day holds with token	Phase 2 (before April)	🧮 no substrate; money path
Order stages per industry and the status link	Phase 2	🧮 fixed CHECK list today
Album frame selection from a delivered gallery	Phase 3	🔎 thousands of photos per wedding; R2 and bandwidth cost unmodelled
Measurement card	Phase 3	📘 personal data; needs a consent model
A wedding folder across vendors, a cross-vendor shortlist	Decision first	🔎 it is the wedding-planner product, and it sits on the consumer boundary
Reviews and ratings	After the request entity exists	🧮 reviews need a record to be earned from
Venues, caterers, decorators, planners, bands	Later	📘 the design agrees; they need dates, quotes and menus
Bridal checkout, AR try-on, in-app negotiation, POS sync	Never	📘 the design agrees

10 · Reusable platform capabilities to build now

In order. None is a wedding module; each is needed by at least three verticals already on file.

1. Public events and attribution (the first slice of ADR-0010). Append-only, no PII, rate-limited, written by one Edge Function; it revives the dead card beacon (QRS-734). Serves every card, the biodata's growth card and the reseller loop (L4). Build first: it is how every later decision gets measured instead of argued.
2. The public share page pattern, generalised from the biodata route: /:slug/… nested segments (no new top-level segment, so ADR-0028 is not touched), an OG image, noindex on token links, and the two-sided growth footer. It serves look pages and selection pages now, and invitations later.
3. Selections. An ordered set of references owned by one workspace (items first; media next, which makes albums the same mechanism), created by the merchant or by an anonymous visitor, readable by a hashed token, with rate-limited anonymous reactions. One mechanism for shortlist, portfolio album and, later, album frame selection. It needs an ADR and check:arch-proposal; the name follows the feature (check:naming).
4. Industry configuration made real. Populated attribute schemas and a resolver, attributes projected on the card, and conversion deriving the primary action. It also needs a season column: the dashboard's season is always null today, and the 90-day inactivity rule needs it.
5. Party + request, the lead entity. 📘 car_sales, real_estate, electrician and direct_seller already need it, and QRS-668 decided the form. Build it immediately after the four above, once D-B is answered.
6. Schedule and date availability after that. The photographer's "are you free on 2 December" depends on it.

11 · Recommended categories for the first scope

Tested against five questions. Is it visual? Does it share natively? Does its archetype have substrate today? Does it convert without a new entity? Does it have a season inside the window?

#	Category	Archetype	Verdict	Why
1	Bridal and ethnic wear, with groom collections	goods	✅ Lead category	🧮 Everything it needs to be shown, shared and ordered exists or is minor. 🔎 Its natural behaviour (photos to the family) is the loop. Groom wear is the same row with groom collections; rental waits
2	Jewellers	goods	✅	🧮 The server already withholds the price, which is what a day's rate needs. 📘 accepted as configuration (QRS-465/466). 🔎 Visual, family-decided, bought for the wedding
3	Photographers and videographers	expertise	⚠ Card-first in November, full value in January	🔎 The most share-native trade and the least served today. Until requests and dates exist, the card must beat Instagram on packages and "ask about this package" alone. Expect slower adoption
4	Bridal makeup and mehendi artists	time	⚠ Same as photographers	🔎 Solo, portfolio-led, date-bound. One industry row or two. This is the entry to "salons", not the salon itself
5	Sweets, faral and rukhwat (existing sweet_shop)	goods	✅ The Diwali bridge	🧮 Orders work today. 🔎 Diwali faral is its peak and wedding rukhwat its bulk season, and a housing-society WhatsApp group is the most forwarded channel in Pune. Not a portfolio trade, but the one that transacts on day one

Not in the first scope:

• General salons. 📘 Tier 2 in revalidation: "a reputation business, and we have zero reputation. Google wins decisively." They also need bookings, which have no substrate.
• Tailors. Their value is order stages, which are Phase 2.
• Purohits. Data-only and cheap, but they are not share-driven. Add them opportunistically.
• Venues, caterers and decorators. They need dates, quotes and menus.
• Marriage bureaus. Excluded.

12 · How each category joins the sharing loop

Category	What gets shared	Who shares, to whom	What the recipient does	How it returns to QR setu	Needs
Bridal and ethnic wear	A selection of looks; a look page	Store staff → bride; bride → mother, aunts, the groom's side	Keep or skip each look; "ask about this"	Asks land with the store; relatives see the store's card and the growth footer	Selections (P), look pages (M), ask action (M)
Jewellers	A selection of sets; rate "on request"	Counter → family; family → relatives	Shortlist sets before the visit	The visit is prepared; the family forwards the jeweller	Same as above
Photographers	The card with packages and film links; later an album	Photographer → lead; bride → family; vendor → vendor	Ask about a package; later check a date	"Worked with" credits carry the studio to other vendors' customers	Ask action (M), credits (M/B); dates in Step 4
Makeup and mehendi	Portfolio album; trial package	Artist → bride; bride → sisters and friends	Ask for the trial; later book it	Credits from the photographer and the boutique	Same as photographers
Sweets and faral	The Diwali or rukhwat order page	Shop → society group; resident → resident	Order	Every order is an attributed conversion; residents who run shops see the footer	Orders (S), attribution (P)

Repeat use 🔎 comes from five functions per wedding (one family returns to the same store and studio), three seasons a year (Nov–Dec, Jan–Feb, Apr–May, plus festivals), and a merchant who uses "send looks" for every customer conversation, weekly, in season. A profile view is one-time; a selection is a tool.

13 · Dependencies between Biodata, Consumer, Merchant and Marketplace

Capability	Depends on	Unblocks
Production exists (26.0.1 promoted)	Owner approvals, store and keystone blockers, CI quota (QRS-790)	Everything customer-facing
Biodata live	Production	Consumer accounts with an address; brand trust; the C→C loop
Attribution	nothing	Measuring every loop below; the merchant's value report
Visual card (photos, cover, preview)	QRS-652, QRS-1442	Every share of a card being worth opening
Industry configuration	Discovery briefs (G-D gate)	Category-specific facets, buttons and SEO pages
Look pages	Per-item read, share-page pattern	Selections
Selections	Look pages, attribution, an ADR	The M→C and family loops
Party + request	Decision D-B, rate limits	Trial requests, briefs; the platform's time and expertise halves
Schedule / dates	Party	"Check your date", advances
Reviews	Request or order records	Reputation, and with it general salons
Invitations	A separate bounded-context plan, decision D-A	Guest-scale reach, vendor credits on invitations
Marketplace browse	Supply density, reviews, the R1-off decision reversed	The directory, last

The biodata is on a parallel track, not an upstream one. It depends on production and on its own remaining waves. The merchant loop does not depend on the biodata, and must not be designed to.

14 · Risks of launching these categories by the end of November

#	Risk	Evidence	Blast radius	Mitigation
1	Production has never been promoted	🧮 Prod has no v2 schema; 174 CRs pending	Total: nothing reaches a merchant	Treat the 26.0.1 promotion as the first milestone of this plan, not a parallel one
2	One developer, four programmes	📘 bus factor 1; the Admin Panel's 5 increments, the biodata waves, the first promotion, this	Everything slips together	One must yield (D-D). 🔎 For 10 to 20 pilot merchants, takedown by SQL runbook is enough, so the Admin Panel can follow
3	No discovery brief for any trade	📘 G-D gate; 🧮 no interviews	The release gate refuses the scope	The marketing person interviews 3 merchants per category in October
4	Diwali (8 Nov) comes before end-November	🌐	Diwali passes before launch	Decide the anchor (D-C). 🔎 A merchant launch only earns Diwali if it is live by about 25 Oct
5	Onboarding merchants in their peak	🌐 muhurats 21 Nov – 13 Dec	Low adoption; the pilot learns nothing	Pilot in Kharmas, 16 Dec – 15 Jan, when there are no weddings and merchants have time
6	Selling capabilities that do not exist	🧮 QRS-1443, QRS-1424	Merchant trust, consumer-protection exposure	Fix the tiles before recruiting anyone
7	Photographers and makeup artists compare the card with Instagram	🔎	Cohort B churns in November	Position them as card-first; lead with bridal and jewellery
8	Image weight	🧮 unpaginated catalogue RPC; r2.dev has no transforms; transform cost on the zone undocumented	Slow look pages on 4G, surprise bills	Pagination and per-set fetch; owner decision on transform cost
9	Privacy of anonymous selections	🔎 a bride's list can carry a budget or a month	Personal data behind a forwardable token	Never ask for a wedding date; no PII in events; tokens hashed; withdrawal like biodata shares
10	Seasonal churn	❓ the design's prototype seeds "16% of churn reasons are seasonal", which QR setu has never measured; 📘 the design's 90-day inactivity rule	Off-season merchants marked inactive	A season column read by the inactivity decision
11	Store distribution	🧮 no D-U-N-S; release APK signed with the debug key (QRS-908)	Merchants cannot install a trustworthy app	Merchants use the web console for the pilot, which needs a parity exception the owner must approve (D-G), or QRS-908 is fixed first

15 · Recommended MVP scope and sequence

🔎 Every duration below is my estimate for one developer, excluding the design round, the three-platform parity pass and Change Records. The sequence matters more than the dates.

Step 0 · Decide and prepare (now → about 12 Oct). Owner answers D-A to D-H. The marketing person runs discovery interviews: 3 per category, 5 briefs. One Claude Design round covers the §7 gaps and corrects QRS-1448. The 26.0.1 promotion path is planned with dates, because it gates everything.

Step 1 · Make a card worth sharing (Oct, about 3 weeks). Everything here helps every category, not only weddings. Mobile item photos (QRS-652), mobile publish (QRS-816), logo, cover and preview image (QRS-1442), the pricing_mode and category writers (QRS-1441, QRS-1447), and "ask on WhatsApp" per item. Also: look pages with previews, the new industry rows with attribute schemas projected on the card, conversion driving the button, the event write path with the beacon revived (QRS-1444), and honest onboarding tiles (QRS-1443).

Step 2 · Selections (Nov, about 2 weeks + ADR). Merchant-built "send these looks" first; then the anonymous family view with keep or skip and the two-sided growth footer; albums as a selection of media; "worked with" credits. Launch the five categories in Pune at Tulsi Vivah (21 Nov), with bridal wear and jewellers leading.

Step 3 · Capture intent (Dec, during the season). Party + request, anonymous, carrying the selection (QRS-668), rendered in the merchant inbox. Pilot with 10 to 20 merchants through Kharmas (16 Dec – 15 Jan), live for the January to February season.

Step 4 · Dates (Jan–Feb). Schedule and "check your date" for photographers and makeup artists; advances through the payment link.

Then: reviews, order stages, quotes, holds and rentals before April. Invitations only after their own plan.

What this means for the brief's two dates.

• Diwali: 🔎 not for the wedding merchants. It is realistic only for the biodata (if production is live) and for the sweets category through the existing order path.
• End of November: realistic for Steps 1 and 2 only if the Admin Panel increments pause and the first production promotion lands in October. Otherwise, the honest date for five categories is the Kharmas pilot.

16 · Decisions the owner needs to make

Id	Decision	Recommendation
D-A	Does the biodata boundary stand, and does it cover invitations?	Yes. Record it as consumer decision D12: vendors may appear on a family's invitation or album only as credits the family itself adds
D-B	QRS-668 (enquiry form, 14 Aug) or "a lead entity is FUTURE" (28 Aug)?	Build it, as Step 3: merchant-side, anonymous-capable, consent by submission, no data flowing from the consumer side
D-C	Diwali or the wedding season as the anchor?	The wedding season. Diwali for the biodata only, if production is live
D-D	What yields for capacity?	The Admin Panel increments beyond what launch needs, until Step 2 ships
D-E	The five categories	Bridal and ethnic wear · jewellers · photographers · makeup and mehendi · sweets and faral
D-F	Who runs discovery, and by when?	The marketing person, 15 interviews by about 12 Oct
D-G	The merchant surface for the pilot	Fix QRS-908 and ship all three platforms, or approve a web-console-only pilot exception explicitly
D-H	Payments live for pilot merchants?	Only for goods orders at first; advances after Step 4

Sources

• 🌐 Diwali and Lakshmi Puja on 8 Nov 2026: Shubh Panchang, Divine Hindu.
• 🌐 Tulsi Vivah on 21 Nov 2026: Dev Aastha.
• 🌐 Vivah muhurats, Nov–Dec 2026 (sources differ on the exact December dates): SmartPuja, Dr R P Sharma.
• 🌐 Kharmas from 16 Dec 2026 to 15 Jan 2027: Sahita, Vedic Match.