Product & architecture revalidation

A clean, current statement of what QRSETU is, what it has actually built, and where the product direction and the code disagree. Authored 2026-08-25 at the product owner's request, as the baseline for a development reprioritisation exercise. Every 🧮 claim below was produced by a command run against this repository on that date.

Part of Strategy: competitor analysis & market positioning — evidence-class legend there. Companion to current architecture state, which holds the same question for the architecture half and which this page corrects in six places (§16).

The headline finding, in one sentence

The platform has built the substrate for one archetype and designed the strategy for the other two. 🧮 Catalogue, Fulfilment and Location have tables; Party, Schedule, Balance, Ledger, Asset and Campaign have none. The goods archetype is shipped and working; time and expertise — which together cover roughly thirty of the ~45 scoped industries, and every category in the proactive-sharer segment — have no record for the only thing their card produces.

0. The commercial and technical baseline, measured

🧮 Measured 2026-08-25 against 69 live migrations, the deployed Edge Function set, the packages/data barrel, the client route tree, the guardrail config, and both parity gates.

	Value	Read
Live migrations · tables created	69 · 55	The schema is substantial and mostly sound
Edge Functions deployed	10	manage-account · manage-item · manage-media · manage-order · manage-reminder · manage-setu-card · place-public-order · provision-workspace · razorpay-webhook · reconcile-payments
packages/data seams real / total	14 / 27	13 are stub-bound, incl. payments, settings, profile and the card editor
Primitives with table substrate	3 of 11	+2 partial. See §12 — this is the decisive number
Analytics tables, anywhere	0	⚠ No analytics_events, no card_events, nothing
Reviews / ratings tables	0	Reputation is not among the eleven primitives
RBAC tables · is_admin()	0 · absent	workspace_members.role_key is bare text default 'owner', no CHECK, no FK
cron.schedule calls · outbox drainers	0 · 0	⚠ Nothing in the platform runs unattended
Industries seeded	14	11 of them are the proactive-sharer kind
Mobile screens built (ledger)	27 / 36	1 stale, 8 missing
Desktop screens with a route	6 / 20	5 have a parity contract
ADRs · still Proposed	29 · 17	Including the whole ADR-0020..0025 platform spine

📘 Carried forward from the 2026-08-18 live Dev probe and not re-probed here: 7 users · 5 workspaces · 5 setu_cards · 6 catalog_items · 19 orders · 18 payments · 1 paying workspace (₹9,999) · 0 conversations. ✅ Media rows are known to be non-zero since, because R2 upload and card render were verified working in the week of 2026-08-18 (QRS-833).

Read the baseline as good news about the code and bad news about the clock

🔎 The backend is genuinely further along than the commercial motion. The problem this page describes is not feature coverage. It is that the four things which make every other feature sellable — measurement, transport, a lead record, and something that runs unattended — are missing, and three of them are days of work.

1. What QRSETU is

Reconstructed from the architecture and the code rather than from the vision documents, several of which are superseded (§16).

QRSETU is a multi-tenant operating layer for Indian micro-businesses, anchored on one public artefact — the Setu Card at qrsetu.com/<slug>/setu-card — where a business's INDUSTRY declares what it sells and which processes it runs, and the platform resolves which capabilities that particular business gets.

The problem it solves. 📘 Not "digitisation" in the abstract. The specific problem is that the operating shape of an Indian micro-business breaks every general-purpose tool: 🌐 too many items for a WhatsApp catalogue (capped at 500, average 25), too short a season for annual SaaS, too informal for a POS, too dependent on one person to run software that assumes a back office. The business's record of itself is a notebook and a chat scrollback.

Who it is for. 📘 Three user categories that differ in schema, not merely in permissions — the most expensive thing in this codebase to get wrong:

	Category	Distinguished by	Governs own industry & plan?
1	Solo owner — primary audience	🧮 1 membership, member_owned	Yes, at onboarding
2	Enterprise	1 membership, org_owned	No — the org admin assigns it
3	Consumer	0 memberships	N/A — no business at all

How the pieces relate. The relationship between merchants, consumers, cards, leads, communication and commerce is a resolution chain, not a feature list:

The claim this structure earns, and the one it does not

🔎 The cost of the platform is O(primitives), not O(industries). That is genuinely true, 📘 verified live (the dairy-vs-boutique applicability derivation resolves with zero grant rows), and rare.

And no merchant will ever pay for it. It decides whether QRSETU survives vertical number six, not whether vendor number one signs up. It is a durability moat, never an acquisition argument — the same conclusion differentiation reached, restated here because it governs every prioritisation call below.

2. What QRSETU is not

Each row is either an explicit written refusal or a measured absence. Keeping the list sharp is what makes "no" cheap later.

Not this	Because
A digital business card	🌐 The category is crowded and price-collapsed
A marketplace	🧮 /marketplace is a deliberate 404 until Discover ships. Zero registered consumers
A CRM	🧮 No parties, no leads, no enquiry table
Billing / GST / accounting	📘 Out of scope. 🌐 One incumbent spends ₹102 Cr of salary to hold that market
A website builder	📘 Retired; the card is a repo-authored manifest, not markup
A lender, escrow or fund-holder	📘 RBI-licensed activity — "the guardrail most easily broken by a future 'let's hold the money until delivery' idea"
A workflow engine	📘 Refused on three grounds, and the third is decisive: a platform that lets vendors invent arbitrary processes cannot be proactive about any of them
Clinical records · manufacturing · fleet · ERP	📘 Different regulatory regimes, different systems problems
Dine-in restaurant operations	📘 F2 fails; dine-in ops is a POS

And one positioning claim that should be retired

📘 "QRSETU is ONE unified platform, not a collection of separate tools." 🔎 Every competitor in this market says this, a merchant with one problem does not want six modules, and — read honestly — it is the sentence that licenses scope creep, because anything can be argued into a unified platform. Replace it with the narrower claim in §13, which is defensible and checkable.

3. Current product thesis

There are three theses in the material, they are not the same, and only one of them is built. Naming them separately is the most clarifying thing in this revalidation.

Thesis	Claim	Substrate 🧮	Verdict
T1 · Commerce	A vendor with 1,500 items and a four-week season has nowhere to put them	✅ built — catalogue, orders, payments, webhook, reconciliation, public order path. Real money has moved	Keep, but it cannot be the organising principle — §11
T2 · Supply-side economics	The twentieth vertical costs a row, not a rewrite	✅ built and verified live	Keep as architecture, never as a pitch
T3 · The instrumented identity	Nothing records the causal chain from a named person to a named customer outcome. The card is identity, surface and event source	🔴 none — card views record nothing, no leads, no scheduler	⭐ Promote. This is the real thesis and it is written down inside a vertical dossier

🧮 The measured fact that undercuts the whole proactive thesis — and it is STILL TRUE

The public Setu Card installs an analytics beacon that posts every view to track-card-event. That function exists only in supabase/functions/_archive_pre_v2/. 🧮 The live set is ten functions and it is not among them. navigator.sendBeacon swallows failures by design.

So every card view has recorded nothing, silently — and it is still true on 2026-08-25, seven days after being found and logged as QRS-734. 🧮 The beacon in apps/web/src/tiers/public/features/setu-card/analyticsBeacon.ts still names the archived function.

The one number QRSETU needs in order to sell anything to a merchant — "your card was opened N times" — is not being collected.

🔎 The stated first principle is proactive, not reactive. That principle is genuinely unusual in a market of passive record-keeping tools, and it is fully honoured and fully inert: with no read model the correct behaviour is silence, and silence is what ships. The most differentiating idea in the product has no substrate, no transport and no scheduler.

4. Current architecture

🧮 Classified as the owner asked: core platform · industry-specific · optional/configurable · still to build.

4.1 Shape of the system

• One Supabase backend — Postgres + RLS + Auth + Edge Functions. 📘 RLS on every table; zero tables directly readable by anon or authenticated.
• 📘 Two frontend stacks by design (ADR-0011) — server-rendered React DOM for the public card and admin; one universal Expo/React Native codebase for the merchant product.
• 📘 Reads go through SECURITY DEFINER RPCs behind a typed packages/data seam. Writes go through Edge Functions with required idempotency keys. supabase.from() is banned in app code, compliance is perfect — and 🧮 nothing enforces it.

4.2 Domain by domain

Domain	Class	State	What is actually there
Core tenancy	Core	✅ built	users, workspaces (tree + materialised path), workspace_members, organizations, workspace_groups, audit log, idempotency ledger, outbox
Authentication	Core	🟡 partial	Google OAuth works end to end. 📘 Email OTP broken since ~1 Aug (SMTP 535 — a credential and SPF problem, not code). ⚠ 🧮 ADR-0018, which governs the whole auth implementation, is cited by 25 code files and does not exist
Authorisation / RBAC	Core	🔴 none	🧮 Zero tables — no roles, permissions, role_permissions, user_roles, platform_admins. No is_admin(). role_key is unconstrained text. 📘 ADR-0006 is Accepted and unimplemented
Industry configuration	Core	✅ built	14 industries, 3 archetypes, 11 primitives, 18 features, 8 grant scopes, 34 grants. Resolver probed live; applicability derived from composition
Setu Card	Core	✅ built	SSR route, manifest renderer, one template, palette axis, lossless switching, purge-on-write invalidation. One renderer, always DOM
Catalogue / commerce	Core	✅ built	Items, variants, categories, media links, pricing modes, resource_holds stock commitment, public projection, buyer order path
Payments	Core	✅ built	Razorpay Route, a split a CHECK proves adds up, append-only payment_events with a replay guard, monotonic status ranking, detect-only reconciler, payout accounts, tax identity. The most rigorous subsystem in the repo
Leads / CRM	Core	🔴 none	🧮 No parties, leads or enquiries. 📘 Four registered features declare customers as their parent and all four are blocked on it. See the callout below
Communication / chat	Core	🟡 partial	8 chat tables + realtime deployed 2026-08-11. Reads live; writes stub-bound, no chat EF. 📘 0 conversations. WhatsApp (ADR-0029/0030) is Phase-0 documentation — nothing built
Marketplace / discovery	Optional	🟡 partial	Consumer item feed with multi-select facets, category and city scoping; Browse live. /marketplace index is a deliberate 404. Zero consumers
Notifications	Core	🔴 none	📘 Remote push does not exist by explicit decision. Email is down. Local notifications only. Transport is a hard prerequisite of every proactive surface
Content / media	Core	🟡 partial	media two-phase, manage-media EF, R2 presigning, upload+render verified. No tagging, no library, no orphan sweeper, no bulk import
Calendar / meetings	Core	🔴 none	🧮 No schedules, bookings or appointments. 📘 The reminders engine (rules + sparse exceptions, 117 tests) is the right shape and is user-owned, not workspace-owned
Analytics	Core	🔴 none	🧮 No analytics table in any live migration. Beacon points at the archive. Mobile has zero wiring. GA4 is on the landing route only
Reputation / reviews	Core	🔴 none	🧮 No reviews, ratings or testimonials table anywhere. Not among the eleven primitives. A scope gap, not a deliberate exclusion
Sharing / referral	Optional	🔴 none	📘 ADR-0005 is Proposed. No share-token model. The forward loop runs whether designed or not — and the product currently forbids the affordance it runs on
Scheduler	Core	🔴 none	QRS-885 — 🧮 Zero cron.schedule calls. outbox exists and nothing drains it. The only recurring job is a GitHub Actions cron, and Actions has been billing-blocked (QRS-790)
Integrations	Optional	🔴 none	🧮 No external_accounts, integrations or oauth_tokens. Google Business, review sync and any DMS integration wait on a token-storage decision nobody has taken
Enterprise / org	Core	🟡 partial	Schema exists (tree, path, ownership model, sharing flags, seats-license-users). Zero organisations, no org-admin portal, RBAC 0%. Design is far ahead of substrate
Campaigns	Optional	🔴 none	📘 ADR-0025 is a good design with no table and no customer
Admin panel	Core	🔴 none	Two READMEs, zero code, in both apps. Gated on RBAC

📘 The structural finding, and it reframes the whole prioritisation question

Leads is not a CRM add-on. It is the missing fulfilment record for an entire archetype.

The expertise archetype's registered definition is "the card generates the enquiry, not the sale" and its output is literally recorded as an enquiry. Five industries sit on it — electrician_plumber · real_estate · car_sales · photographer · direct_seller — and there is no enquiry table and no lead table. orders' own comment concedes it: "all six goods industries gain it while real_estate and salon correctly do not."

So a goods merchant has orders. A time merchant will have bookings. An expertise merchant has nowhere to record the only thing their card produces. Full argument: Leads & CRM architecture fit.

4.3 Genuinely industry-specific capability: almost none

📘 Core vs industry-specific capabilities tested the dealership list item by item. Google Business, reviews, messaging, campaigns, visitor register, leads, bookings, discount approval, targets and dealer-group hierarchy are all core capabilities the dealership needs first, not dealership features. Exactly one item survived as genuinely industry-specific, and it is a compliance rule (the CCI restriction on what an OEM may see of a dealer's data), which belongs on the industry row rather than in code.

⚠ 🧮 And the rule preventing fragmentation is not enforced: no lint guardrail mentions industry, archetype or plan, though CLAUDE.md claims ADR-0021 D4 is lint-gated (QRS-879).

5. What we are actually building

The minimum coherent QRSETU, stated as a product rather than a feature inventory:

A merchant claims a slug, publishes one card that answers the questions they answer fifty times a day, shares it into the networks they already work, and the platform records what happened on the other side of every open — then tells them what to do about it.

Each clause maps to something buildable: claim (built) · publish (built) · share (not built) · record (not built) · tell them (not built).

Journey	State	Where it breaks
Merchant onboards → card published	✅ built	Google-only sign-in; email OTP down
Merchant builds a catalogue	🟡 partial	Item-by-item only. 📘 ~50 hours for a 1,500-item vendor. No bulk paste, no multi-photo draft creation
Buyer scans → browses → orders → pays	✅ built	Works. The strongest journey in the product
Buyer collects against a code	🟡 partial	Consumer OrderCode exists; merchant scan-verify incomplete
Merchant hears about an order	🔴 none	No transport. 📘 "A booking nobody hears about during a four-week season is worse than no booking at all"
Merchant is discovered by a stranger	🟡 partial	City + category browse works. No SEO directory, no reputation signal, zero consumers
Enquiry → lead → follow-up → won	🔴 none	No substrate at all. §11 argues this should become primary
Session / booking → attendance → renewal	🔴 none	No schedule table. 📘 Decided by the owner 2026-08-14, unbuilt
Merchant is told what to do next	🔴 none	No read model, no transport, no scheduler. The stated first principle

Over-engineered, under-used, or misaligned

• 🔎 Payments is engineered well past its current demand — reconciliation runs, dispute tables, settlement ledgers, tax-identity history, a watchdog workflow, against 18 payments. Correct for money specifically (errors are unrecoverable and regulatory), but it must not set the standard of rigour for a lead table.
• The enterprise schema is fully designed with zero organisations. Six ADRs deep, no customer.
• Chat shipped and is unused. Eight tables, realtime, media columns, message actions — no send path, 0 conversations.
• 🔎 The gate and tooling layer is now a second product. 🧮 24+ check:* scripts, 9 workflows, 8 hooks, a release manifest system, an architecture-change protocol. Mostly justified — each encodes a real incident — but it carries its own maintenance cost on a one-developer team, and the newest gates increasingly check documents rather than code.

6. Merchant ecosystem

Capability	State	Note
Onboarding, industry choice, slug claim	✅ built	Desktop onboarding reaches 33/33 parity rows
Setu Card publish + editor	🟡 partial	EF live; setuCardEditor seam stub-bound
Catalogue: add, edit, archive, bulk, photos	✅ built	The deepest merchant feature. Desktop catalogue 37/42 rows
Orders / collections	✅ built	Read RPC + manage-order EF live
Payments, payouts, banking	🟡 partial	Backend rigorous; payments and payoutAccount seams stub-bound
Location & discoverability	✅ built	Fixed 2026-08-22 (QRS-834) — a merchant who skipped the step was permanently undiscoverable with no signal anywhere
Reminders	✅ built	The reference feature
Chat / messages	🟡 partial	Reads only
Dashboard	🟡 partial	Catalogue and features real; order widgets stub; no summary RPC
Analytics	🔴 none	Nothing recorded, nothing to show
Profile / settings / account	🟡 partial	All three seams stub-bound. profileService's EF was archived and its tables dropped — wiring it is a redesign, not a swap
Leads, bookings, sessions, khata, team	🔴 none	Designed, some owner-decided 2026-08-14, no substrate

🧮 Thirteen of twenty-seven data seams are stubs, and this changes how to read "built"

A screen backed by a stub-only seam has proven nothing about the backend. The stub-bound seams: account · chat · collection · consumerActivity · consumerPrefs · dashboard · payments · payoutAccount · platformPlan · profile · settings · setuCardActivity · setuCardEditor.

🔎 So the honest reading of "27 of 36 screens built" is: the screens exist, and roughly half of the merchant console is drawing from fixtures.

7. Consumer ecosystem

🧮 The consumer tier is real: a third tier beside user and admin, nine routes, 10 of 11 designed screens built. ✅ EntryRoute now carries a /consumer branch — the trap where an individual landed on the merchant dashboard has been closed.

What a consumer can accomplish, honestly ranked:

1. Browse and order with no account. Structurally correct: server-rendered, edge-cached, orders.buyer_user_id nullable. 🔎 Hygiene, not differentiation — Google Business Profile and WhatsApp are also frictionless.
2. Hold a collection code. Re-minted on open so a screenshot is refused later, verified against four verdicts. 🔎 The only reason a consumer installs the app.
3. Item-level discovery with facets. Genuinely better than anything available for the festival case, and only for that case.
4. Chat, saved vendors, order history. 🔎 Retention for a user the order acquired.

🔎 The inversion in the consumer product

The acquisition engine is the collection code, and it is fourth in the navigation. The consumer app is designed as a discovery product, leading with browse — but discovery needs a consumer base that does not exist, and the code needs only a buyer who has already paid.

Two cheap consequences: lead the consumer tier with collection, and put one quiet onward affordance on the code screen — "keep your orders in one place", and for the merchant-curious, "run a stall? make your own card". The second is the only place in the product where the merchant → consumer → merchant loop can close, and 📘 it is not designed.

📘 Consumer desktop does not exist in the design at all — all 13 consumer prototype screens are mobile-only, so a desktop buyer can discover, browse and order and then has no order-code, account, orders, chats or notifications surface. That is a design request, not a pull.

8. The Setu Card's role

The card is simultaneously three things, and the strategic question is which one you are selling.

Role	Means	Commercial consequence
A page	A shareable, indexable, no-account public identity	🔎 Commodity. Free from a dozen vendors. Do not sell this
A storefront	A catalogue that holds more than a chat app can	Real and measured — but only for high-item-count merchants, and it carries a ~50-hour onboarding cost
An instrument	Every share attributable, every open an event, every open able to start a recorded workflow	🔎 The defensible one. And the one that currently does not work

What the architecture gets right (📘 ADR-0019, and it is the best-defended boundary in the repo): one renderer, always DOM, always server-side — the app never renders the template, and a check:parity rule bans importing the card manifest into apps/mobile · a template is repo-authored data over a closed block vocabulary, never markup, which is what makes AI-authored templates safe · lossless switching forever, enforced by one gated invariant (a block may reference a field, never contain vendor content) · purge-on-write freshness, never TTL.

🔎 The gap that matters most for the direction being proposed

The card is architecturally excellent as a publication and has no capture mechanism. No enquiry block, no lead landing, no attribution of a share to an outcome.

✅ 📘 The owner already decided (2026-08-14, QRS-668) that an enquiry form block scoped to the expertise archetype ships, landing as a lead with source card enquiry — and it is unbuilt. Every category in §11 depends on that one block plus the table behind it.

9. Business & industry landscape

📘 ~45 industries are scoped across three archetypes. 🧮 14 are seeded: boutique · car_sales · dairy · direct_seller · electrician_plumber · festival_stall · kirana · photographer · real_estate · salon · sweet_shop · tiffin · tutor · yoga_fitness.

🧮 The observation that decides the prioritisation question

Eleven of the fourteen seeded industries are the "proactive sharer" kind — trainers, tutors, agents, distributors, tradespeople, photographers, salons. Only three are the high-item-count commerce kind that the built substrate serves.

So the taxonomy already anticipated this direction. What is missing is not the industry rows. It is the primitives underneath them.

The five-question fit test, and one addition

📘 The written test explains every include/exclude decision and should be kept as-is: F1 found or remembered by individuals · F2 owns its customer relationship · F3 transaction completes without negotiation · F4 small enough that no affordable software exists · F5 the owner is the operator. A no on F1 or F2 is disqualifying.

🔎 One addition, because the current test cannot discriminate inside the segment now being prioritised:

F6 — does the merchant hand this card to people who are not already standing in front of them?

That is the difference between a card that replaces a conversation and a card that creates one, and it is the variable the reprioritisation question is reaching for.

Vertical dossier depth, measured

Vertical	Pages 🧮	Discovery	Read
car_sales	22	🔴 not started	By far the deepest dossier, and its G-D artefact is deliberately at not started. Zero Indian dealers have been asked anything
festival_stall	2	✅ complete	12 real vendors visited. The only vertical with first-person merchant evidence
direct_seller	2	🟡 owner brief	Second-hand but detailed. Willingness-to-pay and self-ranked pains open
real_estate	1	🔴 agenda only	📘 Owner decided solo agents are R1 (2026-08-09) and the session has never been held
intercity_bus	1	—	📘 Correctly rejected

⚠ 🔎 Dossier depth is inversely correlated with evidence quality. The vertical with 22 pages has no interviews; the vertical with 2 pages has twelve. That is how a research programme drifts toward the most reasoned-about vertical rather than the most validated one.

10. Business prioritisation framework

The owner's fifteen criteria collapse into six axes that actually discriminate. Collapsing matters: fifteen weakly-correlated scores produce a ranking nobody can argue with and nobody believes.

Axis	Question	Absorbs	Why it discriminates
A	Share frequency — how often does the card leave the merchant's hands?	frequency · acquisition dependency · need for digital identity	Decides whether the card is a channel or a brochure
B	Post-open workflow — does opening it start something we record?	lead intensity · follow-up · consultation · meetings · repeat interaction	⭐ The axis that separates a platform from a link
C	Substrate readiness — what exists today?	implementation complexity · feature reuse	Converts strategy into weeks
D	Network effect — does one adopter recruit or fund others?	network/distribution effects · relationship-driven selling	The only axis that beats having no distribution
E	Recurring pay — can they and will they pay year-round?	revenue potential · willingness to adopt · WhatsApp dependency	Seasonal revenue cannot compound inside a 12-month target
F	Drag — compliance exposure and support cost per merchant	absent from the owner's list, and decisive	Two people. 📘 Support minutes per merchant is the most important unmeasured number in the business (QRS-748)

🔎 Two structural corrections to the proposed lens

1 · Sharing frequency alone is the wrong primary variable. A consultant who shares a card showing here is what I do plus a chat button is sharing a nicer link — free, commodity, 🌐 dozens of vendors. The differentiator only appears when the card starts something the merchant then operates. So the lens is A × B, not A, and high-A/low-B categories score down, not up.

2 · The pivot gives up the platform's only measured moat, so it must name a replacement. 🌐 The strongest evidence-backed differentiator today is that a WhatsApp catalogue caps at 500 items. That protects a 1,500-idol vendor. A yoga trainer has three packages. The replacement moat has to be the workflow record — WhatsApp holds conversations and cannot hold state: a stage, a follow-up date, an attendance, a renewal. 📘 The dealership analysis reached the same conclusion independently (native chat is the system of record; WhatsApp is reach, never record).

11. Highest-potential industries

Scored on the six axes. H high · M medium · L low; for C (substrate gap) and F (drag), high is bad.

Category	Arch.	A	B	C	D	E	F	Verdict
Trainers, tutors, coaching yoga_fitness tutor	time	H	H	H	M	H	L	🥇 Tier 1 — best risk-adjusted bet
Direct sellers / distributors direct_seller	expertise	H	H	H	H	M	H	🥇 Tier 1 — highest network effect, highest compliance risk
Real-estate agents real_estate	expertise	H	H	H	H	M	M	🥇 Tier 1 — owner already decided R1; two blockers never delivered
Wedding & event vendors photographer + decorator, caterer, mehendi, makeup	expertise	H	H	M	H	M	L	🥇 Tier 1 — ⭐ under-analysed, see below
Consultants, CA, lawyers, insurance & loan agents	expertise	M	M	H	L	H	M	🥈 Tier 2 — highest ARPU, weakest loop, regulated
Trades — electrician, plumber, AC/RO electrician_plumber	expertise	M	H	H	M	M	L	🥈 Tier 2 — a plumber is found, not shared. AMC recurrence is the real hook
Salon, spa, wellness salon	time	L	H	H	L	M	L	🥈 Tier 2 — a reputation business, and we have zero reputation. Google wins decisively
Festival stall festival_stall	goods	L	M	L	M	L	H	✅ Ship it — built, weeks out. But stop letting it organise the platform
Kirana, dairy, tiffin	goods	L	H	H	L	L	M	🥉 Tier 3 — the khata is an adoption wedge and 🌐 a falsified revenue wedge
Car dealership (enterprise)	goods	M	H	H	M	H	H	🥉 Tier 3 — unbuilt surface, no RBAC, no reference customer, no interviews

Why trainers/tutors is Tier 1 despite being the least exciting

🔎 They already bill monthly, so they have monthly cashflow and a monthly mental model. Every other candidate has to be persuaded into a subscription; this one already lives in one. Add: lowest compliance drag on the board, and it shares its entire substrate (schedule + parties + balance) with direct sellers — so it is not a separate build. The post-open workflow is real and recurring: enquiry → enrolment → monthly fee → attendance → renewal, and 📘 batch timings, attendance and per-student balance are state WhatsApp structurally cannot hold.

Direct sellers: highest network effect, and a hard compliance gate

📘 The network effect is uniquely strong and pre-aligned — an upline is compensated on downline volume, so better tooling for the team directly pays the buyer. One coach adopting the sessions module makes thirty agents participants and every participant a prospective merchant. No procurement, no MSA. 📘 It also has the strongest proactive-value answer of any vertical evaluated, with two independent engines (reorder cycle, session participation) both grounded in stored rows.

⚠ And it is 📘 the highest-risk vertical evaluated. Income claims fall under the Consumer Protection (Direct Selling) Rules 2021; health claims under FSSAI. A distributor writing "earn ₹50,000 a month" on qrsetu.com/<slug> makes QRSETU the publisher. Session titles are the same claim class in a new surface.

🔎 Recommendation: build the substrate now — sessions, leads and groups are all core capabilities serving ≥3 industries each — and gate the public card behind a non-removable disclaimer, a compliance profile and a takedown runbook. The build is Tier 1; the public launch is gated on a legal read that has not happened.

Real estate: decided, and quietly stalled

📘 The owner decided 2026-08-09 that solo agents are R1, which promoted two items to R1 blockers: the property typed field set (QRS-459) and the item-attribute-schema decision (QRS-452). 🧮 Neither was delivered, and the discovery session (QRS-454) has never been held.

✅ But the blocker is now smaller than when it was filed: 🧮 the facet mechanism it needed has since been solved for the marketplace — catalog_items.attributes jsonb with @> containment matching and jsonb_each_text facet counting. So this is now a decision about which fields are typed, not a mechanism to invent.

⚠ The risk to settle first is authority to market. An agent must be RERA-registered, and "B's listing on A's card" needs a recorded authorisation. There is nowhere to record it.

⭐ Business opportunity, raised unprompted: the wedding-vendor referral web

🔎 twelve-month-priorities H8 lists weddings as one of three seasonal verticals to scope and never analyses it. It beats the two named beside it (Navratri, Diwali) on three independent counts, and it fits the proactive-sharer lens almost perfectly:

• The season falls INSIDE the target window — November 2026 to February 2027. 📘 Ganapati fires once before August 2027; the wedding season fires during it.
• The vendors actively refer each other. A decorator recommends a caterer recommends a photographer recommends a mehendi artist. 🔎 That is a merchant-to-merchant loop that runs on supply, needs no consumer base and needs no capital — the only kind of loop two people can push.
• Same substrate as Tier 1 — Party + Schedule + advance/milestone balance. No new primitive, and 🧮 the advance-payment path is already built and proven.
• High share frequency with a real post-open workflow — a portfolio is the pitch, and the open leads to a date enquiry → advance → deliverable handover.

⚠ The weakest link, stated: extreme seasonality per vendor, and a booking is a once-per-customer event, so there is no repeat-consumer loop. ❓ Willingness to pay is unvalidated like everything else. It deserves a discovery brief before the Ganapati season closes, not after.

12. Reusable platform primitives

The most decision-relevant table in this document.

Primitive	Substrate 🧮	Tables that exist	Industries it unlocks
Catalogue	✅ built	catalog_items + variants, categories, media, attributes jsonb	All of them
Fulfilment	✅ built	orders, order_items + the whole payment chain	The 6 goods industries
Location	✅ built	locations, states, cities	Multi-outlet anything; discovery filtering
Recurrence	🟡 partial	reminders, reminder_occurrences — user-owned + a 117-test expansion engine	The engine is right and the ownership is wrong for business use. Needs a workspace-owned sibling
Resource	🟡 partial	resource_holds — stock commitment only, not a bookable resource	Salon chairs, driving-school vehicles, courts, rooms: none
Party	🔴 none	—	Everything relationship-driven. 📘 4 registered features blocked on it
Schedule	🔴 none	—	The entire time archetype — ~13 industries
Balance	🔴 none	—	Khata, memberships, term fees, advances. 📘 "the strongest product wedge in this entire scope"
Ledger	🔴 none	Money-movement ledgers exist for payouts; no merchant business ledger	Manual sale records, khata movement
Asset	🔴 none	—	AMC, service history, the customer's vehicle. 📘 The FK is already written in ADR-0024
Campaign	🔴 none	—	Enterprise differentiator with zero organisations

🧮 The arithmetic that should decide the next build — and it favours the pivot

The three primitives with full substrate (Catalogue, Fulfilment, Location) serve the goods archetype — about 16 industries. The three unbuilt ones that matter most (Party, Schedule, Balance) serve time plus expertise — about 30.

🔎 So the unbuilt primitives unlock roughly twice as many industries as the built ones, and they are three tables. The proposed pivot is not a departure from the O(primitives) model — it is the model's own next step, and that is a far stronger argument for it than sharing frequency alone.

Build once → configure → reuse: worked through

Capability	Primitives	Same code, different word
Lead pipeline	Party + Schedule	enquiry (trades) · prospect (distributor) · requirement (agent) · walk-in (showroom) · admission enquiry (tutor)
Bookable slot	Schedule + Resource	appointment (salon) · class (tutor) · session (distributor) · site visit (agent) · test drive (dealer) — 📘 vocabulary, not a feature
Recurring commitment	Recurrence + Balance	standing order (dairy) · membership (gym) · term fee (tutor) · AMC (electrician) · retainer (consultant) · reorder cycle (distributor)
Running account	Balance + Ledger	khata (kirana) · advance (photographer) · milestone (designer) · fee balance (tutor)
Group of people	Party + Schedule	batch (tutor, distributor) · team (upline, staff) · audience (campaign)
Serviced thing	Asset + Recurrence	vehicle (dealer) · installed AC (technician) · managed flat (agent) · equipment (gym)

🔎 One primitive-set change worth arguing for: usage-based recurrence. Recurrence today is date-based only, and an odometer, machine-hours, printer pages and equipment cycles are the same trigger shape. That clears the ≥3-industry gate and is an extension of an existing primitive rather than a twelfth one.

🔎 And one to argue against, despite agreeing it is needed: reputation should be a capability over Party, not a twelfth primitive. First version = a Google review funnel plus a rating block on the card, which needs no moderation, no takedown obligation and no defamation exposure. First-party order-gated reviews come later, if evidence demands it. See product-gaps G3.

13. Differentiation

There is a defensible answer, it is narrower than the documents claim, and it is not what they lead with.

QRSETU is the only product where a micro-business's public identity and its operating record are the same object — so every share is attributable, every open can start a workflow, and the follow-up belongs to the merchant instead of being buried in a chat thread.

Leg	Why nobody else has it	Verdict
Identity = instrument	WhatsApp gives reach with zero attribution. Google gives discovery with zero workflow. A link-in-bio gives a page with no record. The card is the share and the event source	⭐ The real one — and 🧮 currently false in implementation
Configuration, not code, per trade	Genuinely rare, and verified	Keep — merchant-invisible; sell it as "you are not waiting for a version built for someone else"
Anonymous-first public surface	Google and WhatsApp are also frictionless	Hygiene — table stakes done right, not a differentiator

The one sentence that matters most on this page

The differentiator is a design, not a product. Leg 1 requires that a share be attributable and an open be recorded. 🧮 Card views record nothing; there is no lead table; there is no scheduler to fire a follow-up.

Until those three exist, QRSETU's actual differentiation is a catalogue that holds more items than WhatsApp allows — which is real, measured, and applies only to high-item-count merchants, i.e. not the segment now being prioritised.

Say this	Stop saying this
"One link that answers the five questions you answer fifty times a day."	"A unified platform, not a collection of tools." — every competitor says it
"Your paper slip becomes a code your customer cannot fake."	"Our consumers will find you." — 📘 false until consumers exist
"Every enquiry lands somewhere, with a stage and a date, instead of scrolling away." — the pivot's pitch	"Own your customer, avoid commission." — answers an aggregator pain our verticals do not have, and 📘 we charge 5%
"Adding your trade is a configuration change."	Any comparison to Western website builders or link tools — 🔎 wrong contest, wrong continent

14. Platform flywheel

It is architecturally coherent and operationally inert — five named breaks, four of them days of work.

Loop 1 — merchant → card → share → open → enquiry → customer → repeat → more sharing

#	Break	State	Consequence
1	Nothing is measured	🔴	Cannot prove the loop turns, so cannot sell the renewal or ground a nudge
2	No transport	🔴	The enquiry never reaches the merchant
3	No lead record	🔴	The enquiry has nowhere to land, so the loop ends at the open
4	No reputation	🔴	A stranger opening a shared card has no trust signal
5	No scheduler	🔴	No follow-up fires, ever

⭐ 🔎 The strongest argument for the pivot — stronger than the one that was made for it

This loop was never real for the festival vertical, and it is real for the proactive-sharer segment. A stall vendor shares their card at the stall, to a buyer already standing in front of them — so there is no discovery step, and the card replaces a conversation rather than creating one. A trainer, agent or distributor shares it into networks they do not control, which is a genuine discovery step.

So the pivot does not merely change the segment. It is what makes the flywheel a flywheel rather than a diagram.

Loop 2 — merchant → customers → referrals → new merchants

🔎 Measured-weak, and cheap to fix. It needs a consumer to think "I could have one of these", which requires the card and the order-code screen to visibly be a product. 📘 Neither carries an onward affordance today. One quiet line on the highest-trust screen in the product is the whole implementation.

The loop nobody has costed, and it is the best one available

📘 Merchant-to-merchant adoption needs no capital and no consumer base. A stall vendor is surrounded by forty competitors who watch what works. An upline has thirty downline agents whose tooling they are motivated to improve. A decorator refers a caterer. 📘 Six of the seven documented loops run on supply; the seventh needs a consumer base, is the largest engineering investment, and is the one being built.

🔎 And the highest-leverage loop of all — resellers and trade associations — appears in no portal page outside virality-and-adoption L4 and requires no engineering. One market association or mandal federation is one conversation and 50-200 vendors. 📘 Half the two-person team has no documented workstream, and this is it.

15. What is working

Stated plainly, because the rest of this page is critical and the engineering here is genuinely good.

• The money path. Real payments, a split a database constraint proves adds up, an append-only event ledger with a replay guard, monotonic status ranking, a detect-only reconciler that made 📘 five of seven measured money-safety defects structurally unreachable rather than merely fixed, and a disclosure boundary a test pins. 🔎 Better than most funded startups have.
• The four-layer platform model, verified live. Applicability derived from composition, not a dense industry × feature matrix.
• The card rendering architecture. One renderer, repo-authored manifests, lossless switching enforced by a gated invariant, purge-on-write freshness. The reference, never contain rule is what makes the co-broking and builder-campaign shapes free rather than expensive.
• The catalogue and the facet mechanism. 🧮 attributes jsonb with containment matching and key counting solved a question current-state still lists as unsolved and retrofit-expensive.
• Consumer identity was in the first schema. Nullable buyer references, a users row for every principal. Shipping category 3 is a client build, not a migration — exactly the payoff the decision was taken for.
• The epistemic discipline. Evidence classes, mutation-tested gates, enumeration-before- conclusion, corrections recorded rather than silently rewritten. 🔎 Load-bearing: it is why this revalidation could be done by measurement in an afternoon instead of archaeology over a week.
• ✅ Entitlement presentation is now wired. 🧮 entitlementSource is consumed by useCapabilityState, so a feature blocked by plan can present as locked while one that does not apply stays absent. That seam existed unused for months.

16. What appears stale or misaligned

🧮 Found by measurement on 2026-08-25.

Artefact	What is wrong
CLAUDE.md ADR list (QRS-887)	Enumerates 0019-0028. 🧮 ADR-0029 and ADR-0030 exist — the two newest cross-cutting decisions are absent from the operating manual's own list
CLAUDE.md mobile tabs	Documents {dashboard, chats, leads, more}. 🧮 Actual: dashboard, chats, catalog, more. No leads route, no leads feature (QRS-875)
CLAUDE.md lint claim	States ADR-0021 D4 is lint-gated. 🧮 No guardrail mentions industry, archetype or plan (QRS-879)
CLAUDE.md on apps/web deps	Says no shadcn, radix or cva dependency at all. 🧮 class-variance-authority is a dependency now; radix and shadcn are still absent
current-state	Maintained 2026-08-13, 12 days stale. Lists facets as unsolved and retrofit-expensive — solved. Predates the desktop console, the marketplace browse work, ADR-0029/0030 and the whole car_sales dossier
product-vision	Still a DRAFT carrying a retired decision log and a 248-template target. Its go-to-market wave names Restaurants and Schools, both of which industry scope excludes with a reason
ADR-0018	🧮 Cited by 25 code files and two SQL files, and does not exist. The decision governing the entire auth implementation lives only in scattered comments
ADR status field	🧮 17 of 29 ADRs are Proposed, including the ADR-0020..0025 spine everything is built against. 🔎 The vocabulary has stopped discriminating
Screen ledger vs desktop	🧮 The 16 designed desktop console screens appear in no row of screen-conformance.json — a separate gate had to be built to hold that denominator
delivery-log	Review trigger was 10 entries or 2026-08-31; the log stands at 29 and the review has not happened. Observation #11 is missing from the sequence
QRS-734	Found 2026-08-18 and 🧮 still true on 2026-08-25. The beacon still names the archived function. The one item on this list with a direct commercial cost

🔎 The pattern, which is more useful than the list

Arithmetic drift is now caught automatically and judgement drift is not. check:claims measures the repo on every push and fails if counts disagree, so a stale number is a failed push. But every item above is a stale CLAIM: a decision that moved, an enumeration that got shorter, a gate asserted and never wired. No gate can decide whether a recorded decision is still the right one.

That is the argument for running this revalidation on a trigger rather than an intention — see the bottom of this page.

17. What should be challenged

Six challenges, ordered by cost of being wrong. Each names what would change the conclusion.

C1 · The desktop DOM merchant console contradicts ADR-0011 and is being built past the conflict

Logged as QRS-886.

🧮 4 of 16 designed desktop console screens are built in DOM — a second implementation of the merchant product, in an idiom the app does not have. apps/web/src/ui holds 4 primitives; apps/mobile/src/ui holds 42. Nothing compares them. 📘 ADR-0011 (Accepted) says the merchant product is one universal Expo codebase reaching desktop through RNW, and 📘 ADR-0028's /app mount gives desktop the existing product today.

🔎 This is O(surfaces) cost taken on by a one-developer team — precisely the trap ADR-0011 was written to avoid — and 📘 the design registry's own instruction for a separate DOM console has never been reconciled with the ADR (recorded in desktop-journey-readiness). Component parity between the two idioms is currently unverifiable by construction.

What would change this: evidence that desktop merchants are a distinct paying segment whose density needs cannot be served by RNW. 🧮 That evidence cannot exist yet — there is one paying merchant.

C2 · RBAC being 0% built silently caps every network motion in the plan

🧮 Zero tables, no is_admin(), role_key as unconstrained text. Every multi-person motion needs it: upline teams, dealer groups, coaching institutes with staff, builder channel partners, the admin panel, and the oversight boundary that keeps a downline's customers private from their upline. It is bigger than any one vertical and it is scoped inside none of them.

C3 · The proactive thesis has no execution substrate, and that is worse than the analytics gap

Logged as QRS-885.

🧮 Zero cron.schedule calls. The outbox exists and nothing drains it. The only recurring job runs on GitHub Actions, which has been billing-blocked. Every nudge, session reminder, follow-up SLA, campaign send and scheduled purge needs unattended execution. 📘 A campaign's running state with no worker behind it sits at running forever.

C4 · No vertical has willingness-to-pay evidence, and the plan prices four of them

📘 The festival brief's pricing question returned NA. The direct-seller brief records willingness-to-pay as explicitly open. No dealer has been asked anything. 🔎 Four questions close before the season and none needs a line of code — revenue-model §7 V1, V4, V5, V8.

C5 · The car_sales dossier is 22 pages of reasoning about a vertical with zero interviews

🔎 The research has produced genuinely valuable platform-wide work — the capability classification, user lifecycle, data continuity, the admin control plane. Keep the research and separate it from the vertical. The vertical needs a surface that does not exist, RBAC that is 0% built, and a sales motion two people do not have; 📘 the dossier's own conclusion is 20-30 logos by August 2027.

C6 · "Proposed" has stopped meaning anything

🧮 17 of 29 ADRs are Proposed, including the whole spine that 69 migrations are built against. 🔎 Either accept them or introduce Implemented-Provisional. A status that applies to both we might do this and this is the schema cannot be cited in an argument, which is the one job an ADR status has.

18. What should be removed or deprioritised

A gap list that only adds is a wish list. These should be actively declined for this horizon.

Do not build now	Call	Reason · and what would release it
Desktop DOM console beyond what exists	🛑 stop	Second implementation of one product against an Accepted ADR. Mount the universal app at /app. Releases when paying desktop merchants exist and RNW measurably fails them
In-app marketplace depth — facets, vendor feed, recommendations, Discover	⏸ finish & stop	🔎 Retention for users other loops acquire, not acquisition. 10 of 11 screens built — finish, ship, stop
Campaigns engine	⏸ defer	Good design, 🧮 zero organisations. Releases behind a paying enterprise customer
Org-admin portal + dealership enterprise	⏸ defer	A fourth surface needing an ADR amendment, a design pass, RBAC and enterprise sales capacity
Targeted / profiled advertising	🛑 cut	📘 Reverses ADR-0010 D7's counts-only decision, brings DPDP profiling duties, needs a consumer base that will not exist
Third-party ads on cards	🛑 answer no	📘 ADR-0004's brand question has been open since July and compliance_profile does not exist. Answer it no and stop carrying it as an option
Khata as a revenue line	⚠ reprice	🌐 The most thoroughly falsified revenue hypothesis in Indian SMB software. Build for retention; price something else
Multi-template picker, palette gallery	⏸ defer	Choice paralysis before a merchant asks
First-party reviews	⏸ sequence	Moderation, takedown and defamation exposure. Do the Google funnel first
Native push	⚠ decide	📘 Needed for the store ship anyway. Decide deliberately rather than by deferral — it has been deferred by omission for months
White-label · API · developer programme · bulk B2B QR	🛑 disown	🔎 Each implies a partner manager, a dev-rel function or a sales team. The archived projections should be explicitly disowned, not merely banner-stamped
A second card-product abstraction (event cards, vCards)	🛑 cut	📘 No second card product exists; the standing rule already forbids a shared contract across card products that do not exist
New gates on documents	⏸ pause	🔎 The tooling layer is now a second product, and the newest gates check prose correlation rather than code. Build the next gate when its absence has just cost something

Should be an integration, never a native capability

• Reviews → Google Business Profile. Complement the competitor we cannot beat.
• Video hosting → YouTube links. 📘 Already the decision for the direct-seller card, and it should be the platform default: 📘 measured at ~300× the photo footprint per item.
• Meetings → bring-your-own link. 📘 Already decided. Do not build conferencing.
• Accounting, GST, payroll → never. Export, at most.
• Maps and local search → Google. Do not attempt to out-discover it.

19. What should be built next

One recommendation, not a menu. Ordered so each wave makes the next sellable.

Wave 0 — make the instrument real (days, before anything else)

Nothing in Wave 1 is sellable without these, and none is a feature.

1. Repoint the analytics beacon at a live destination. A minimal card_events table (slug, event, day, count), one anon-callable increment, one dashboard line. 📘 The taxonomy and the client beacon already exist; only the destination is missing. 1-2 days, and it is the highest-value work available in the product — the only thing that turns the renewal conversation into a number. (QRS-734, product-gaps G1)
2. Fix the email credential and merge the SPF include. Hours. 📘 One SPF TXT record only, ever — merge, never add a second. (QRS-285)
3. Give the platform a scheduler. One Edge Function on pg_cron draining the outbox. 2-3 days. ⚠ Not on GitHub Actions — that is the substrate that has already been billing-blocked.

Wave 1 — the pivot's substrate: three tables that unlock two archetypes

1. parties — the Party primitive, not a bespoke contacts table. Carry bothphone_e164 and user_id, both nullable, with a constraint that at least one is present: 📘 an anonymous buyer is phone-only, a chat consumer is account-only, and the platform currently identifies the counterparty three incompatible ways. Keep consent keyed on the phone. Merging two parties is an audited, reversible act — never a matching heuristic. Unblocks four already-registered features at once. (leads-and-crm)
2. leads — workspace_id NOT NULL from the first migration, RLS by membership, 📘 the six-stage vocabulary the owner already confirmed, a follow-up date. One table, two presentation surfaces.
3. The enquiry form block on the card, scoped to expertise — 📘 already decided 2026-08-14. Consent-carrying, rate-limited, fail-closed. This is the capture mechanism the card has never had.
4. schedules + sessions — rules plus sparse exceptions, mirroring ADR-0016 but workspace-owned. Join link fetched on open, which 📘 dissolves the share-the-link-ten-minutes-before workaround with no push infrastructure. Serves trainers, tutors, coaching, distributors and consultants from one build.

Then, and only then: RBAC (it gates every network motion) → the Google review funnel → bulk catalogue ingestion → the public SEO directory.

Non-engineering work that outranks most of the above

Do this	Why it outranks engineering
Sell done-for-you setup at ₹5,000-15,000	Zero engineering. Removes the measured #1 adoption blocker instead of arguing with it, seeds the catalogues everything waits on, produces reference cards, and generates the willingness-to-pay evidence no brief has (QRS-746)
Recruit resellers and one association	📘 The only route past ~50 merchants, and the only workstream that uses the half of the team with no documented one
Concentrate the launch cohort in one market	🔎 One saturated market is a reference; twelve scattered vendors are twelve anecdotes — and a visibly empty neighbour's card is negative virality in the same channel
Instrument support minutes per merchant	❓ The most important unmeasured number in the business. It decides whether merchants below ~₹5,000/year are viable at all (QRS-748)
Write the wedding-vendor discovery brief	The only additional season falling inside the target window (§11)

20. Open architectural & product decisions

Every one is genuinely open — not resolvable by reading.

#	Decision	Owner	What it blocks
D1	⭐ Does the primary product become the relationship layer (time + expertise), or stay the commerce layer (goods)?	Product	Everything below. Recommendation in §21
D2	Desktop: DOM console, or the universal app mounted at /app? (QRS-886)	Architecture	Being built past today, in a second idiom, against an Accepted ADR
D3	When does RBAC get its own wave?	Architecture	Admin panel, teams, dealer groups, oversight privacy, org anything
D4	Scheduler substrate: pg_cron, Supabase scheduled functions, or external? (QRS-885)	Architecture	Every proactive surface. Actions is billing-blocked, so the status quo is not an option
D5	Reputation: capability over Party, or a twelfth primitive?	Architecture	The largest absent capability
D6	Which property fields are typed for real estate?	Product	📘 Declared an R1 blocker 2026-08-09, never delivered. 🧮 The mechanism is now solved, so this is a field-list decision
D7	Direct-seller legal read — disclaimer wording, brand-affiliation policy, public before/after	Owner + legal	The highest-network vertical cannot go public without it
D8	Advertising: answer ADR-0004's brand question no and close it?	Owner	Open since July; carrying it as an option has a cost
D9	Does expertise get orders and payments at all, or only enquiries?	Architecture	📘 The direct-seller commerce leg is deliberately off-platform. If that generalises, the payment rail is a goods concern and the entitlement model should say so
D10	Target restatement: exit run-rate, or cumulative gross contingent on the channel?	Owner	📘 A pre-committed decision is already dated 2026-11-30
D11	Native push — decide rather than defer	Product	Needed for the store ship anyway
D12	ADR status vocabulary — accept the spine, or introduce Implemented-Provisional	Architecture	17 of 29 Proposed makes the field uncitable

Unknowns that are research tasks, not decisions. ❓ Willingness to pay in every vertical · support minutes per merchant · whether an upline will pay for downline seats · whether buyers will pay advances online rather than in cash · whether a local reseller will carry this at 30-40% · where merchants say their customers actually find them. 🔎 Four of those six close for the price of six conversations, and none needs code.

21. Recommended strategic direction

⭐ The recommendation, in one paragraph

Ship the festival season as built, and stop letting it organise the platform. Then spend the next increment on three tables — parties, leads, schedules — plus the enquiry block, a live analytics destination, a working email credential and a scheduler. That set turns the Setu Card from a publication into an instrument, serves the time and expertise archetypes covering roughly thirty industries, and makes the flywheel real for the first time.

🔎 The proposed pivot is right, and the strongest argument for it is not sharing frequency — it is that the loop was never closed for the segment currently built, and closes structurally for the segment being proposed.

The proposed hierarchy

Level	Statement
North star	A micro-business's public identity and its operating record are the same object — so every share is attributable and every open can start a workflow the merchant owns
Core merchant value	"Every enquiry lands somewhere, with a stage and a date, instead of scrolling away — and you are told what to do next."
Core consumer value	"Proof of what you bought, that cannot be faked" — the collection code. Everything else is retention for a user the order acquired
Primary card experience	Answer the five questions the merchant answers fifty times a day — then capture, via the enquiry block. Publication plus capture
Highest-value workflows	Lead capture → stage → follow-up · session/booking → attendance → renewal · catalogue → order → handover code
Platform capabilities	Analytics · transport · scheduler · RBAC · reputation · share rail — in that order. All six are prerequisites, none is a feature
Priority industry modules	🥇 Tier 1: trainers/tutors/coaching · direct sellers · real-estate agents · wedding & event vendors. 🥈 Tier 2: consultants and regulated professionals · trades · salon. 🥉 Tier 3: kirana/dairy/tiffin · dealership enterprise
Secondary / future	Marketplace depth · campaigns · khata · org-admin portal · consumer create-and-share · ONDC · multi-template

Three conditions attached to the pivot

1. Do not abandon the commerce path — harvest it. It is built, it works, real money has moved through it, and 📘 it is the only vertical with first-person merchant evidence. Ship it, measure it, let it fund the pivot. But its economics cannot compound inside the window, so it must stop being the thing the roadmap is organised around.
2. Name the replacement moat explicitly, in writing. The pivot gives up the one measured structural differentiator the platform has (🌐 the WhatsApp catalogue cap). The replacement is state WhatsApp cannot hold — a stage, a date, an attendance, a renewal. ❓ If that claim does not survive contact with a real trainer or agent, the pivot is a segment change without a moat — and that should be known before building three tables.
3. Fix the instrument before selling the instrument. 🧮 Card views have recorded nothing for weeks. Every argument here about attribution, proactive nudges and renewal conversations is a design until that beacon points somewhere live. 1-2 days, and it should happen before anything else.

The one thing to take from this page

The engineering is ahead of the commercial motion, and the plan keeps adding engineering.

🧮 A live money path, a verified four-layer platform model, 69 migrations, 55 tables, 24 gates — against 📘 one paying customer, nothing measured, no message able to reach anyone, and nothing that runs unattended.

The next three weeks should contain almost no new features. They should contain a working email credential, one number per merchant, something that runs unattended, three tables that unlock two archetypes, and five conversations with people who might sell this for us.

How this was produced, and when it goes stale

Every 🧮 claim came from a command run against this repository on 2026-08-25: the migration set, the deployed Edge Function list, the packages/data barrel, the client route tree, the guardrail config, screen-conformance.json and check:desktop-parity. 📘 claims cite QRSETU's own portal. 🌐 figures are carried forward from the strategy section and were not re-verified here. The live Dev row counts are the 2026-08-18 probe carried forward and labelled 📘 for that reason — this page did not re-probe the database.

What this deliberately does not do. It does not re-derive the architecture on its engineering merits — the ADR spine is sound and is questioned here only where a decision carries a commercial consequence the documents do not name. It does not validate the market: every conversion, price-sensitivity and demand assumption remains ❓.

Revisit triggers — this page is stale when any of these fires

🔎 A living document needs a condition, not an intention. 📘 The delivery log's own trigger was passed at 26 entries and never actioned, so these are observable events:

• The Ganapati 2026 season closes (after ~2026-09-25). Every ❓ on revenue-model should become 🧮 within two weeks.
• parties / leads / schedules land, which invalidates §12's substrate table and therefore §11's C-axis scores.
• QRS-734 closes. §3 and §13 both rest on the beacon being dead.
• D1 or D2 is decided (§20).
• Headcount changes. Everything here is prioritised for two people; a third pair of hands invalidates the ordering, not merely the pace.

Related

• Strategy index · Differentiation · Competitive landscape · Product gaps · Virality & adoption · Revenue model · 12-month priorities
• Current architecture state · Core vs industry-specific capabilities · Leads & CRM architecture fit · Industry scope