Appearance
Consumer strategy — evaluation
Assessed 2026-08-28 through five independent expert lenses (solution architecture, product research, product strategy, engagement architecture, and a red team briefed to argue against), each adversarially challenged, plus a completeness critic asked only what all five missed.
THE HEADLINE, AND IT IS ABOUT THIS RESEARCH RATHER THAN THE PRODUCT
QRSETU already decided this question, and none of the 17 pages in this section cited the decision.
QRS-531 is 🅿 PARKED — post-Ganapati, names "marriage biodata" explicitly, describes the identical viral loop, and carries this warning in its own title:
"THE HIGHEST-LEVERAGE ITEM IN THIS SECTION AND THE ONE MOST LIKELY TO BE MIS-SCOPED AS A FEATURE"
QRS-527 goes further: "the second growth loop… is a SECOND PRODUCT that must not enter R1."
This research scoped it as a feature. That is the exact failure QRS-531 predicted, and QRS-589 records the same shape happening before: "I ARGUED AGAINST COMMISSIONING CONSUMER DESKTOP AND NEARLY RE-DERIVED A DECISION THIS TRACKER ALREADY HOLDS."
A. Executive assessment
The strategy is sound. The timing is wrong. The repository said so first.
| Question | Answer |
|---|---|
| Is the consumer direction strategically right? | Yes, and better supported by the platform than expected |
| Is marriage biodata the right wedge? | Probably not the first one — see B |
| Should building start now? | No. QRS-531 parks it post-Ganapati; QRS-527 excludes it from R1 |
| Is the research wasted? | No. The decisions in it are real and will be needed |
Three measured facts that settle the sequencing:
releases/production-state.md:23— "Nothing has shipped through this system yet."- Ganesh Chaturthi is 14 September 2026 — 17 days away, and the festival-stall brief calls it "external, annual, unrepeatable."
- The merchant money loop's terminal step (
scan_collect) is not built on either side.
Recommendation: keep the research, take the four cheap decisions, build nothing until the merchant loop closes and Ganapati has passed. An unrepeatable annual deadline 17 days out beats a second product line every time.
B. Marriage Biodata — product assessment
The problem is real. The pain is narrower than this research implied.
People are not miserable sending PDFs; they are mildly inconvenienced. The acute pain is three things: information going stale after sending, calls continuing after the match is fixed, and photo control. That trio is the wedge; the rest is comfort.
And it is intense, brief and once-per-lifetime, not frequent. The plan prices it as recurring.
⚠ The differentiation claim was wrong, and this is the correction that matters most
An earlier version of Research called this "a clean, unoccupied position." paperprofile.in already ships, free: a permanent shareable link, edits reflected on already-shared links, phone hidden on the public profile, choose-who-sees-contact, private by default and not indexed, view analytics, and delete-kills-the-link. ₹149 one-time.
Four of the five proposed MVP capabilities already exist in a free product. Only proposal status is not in evidence.
The search space was the four sites supplied; the conclusion was drawn about the category. That is QRS-451 exactly.
What survives as differentiation is mostly the platform, not the feature: proposal status, an access-request workflow, the identity layer, and the marketplace behind the same account. QRSETU's advantage here is being QRSETU.
C. Viral growth
The loop is architecturally free — ADR-0019 already mandates no-install web viewing, so the hardest precondition is met.
But the weakest link is not where this research put it. I claimed viewer→creator. The strategist is right that it is registration→published: it is the only one of K's three terms the product controls, and the activation gate (account, slug, form, photos, disclosure choices) is longer than the free competitor's entire product.
And most recipients cannot create one. A biodata reaches parents, relatives and family friends — creator-eligible are the prospective families, perhaps 2–4 of 15. Any model multiplying 15 by a generic rate overstates K by 4–7×.
The reliable multiplier is the marriage bureau, not K. One bureau produces dozens of profiles and multiplies without needing K ≥ 1 — and ADR-0022/0023 organisations, workspace trees and seat licensing already express it. ⚠ But a bureau's business is charging families for introductions. A product that lets families circulate directly disintermediates the channel it depends on. That conflict is unexamined.
D. Consumer lifecycle
| Stage | State |
|---|---|
| Acquire | Strong — WhatsApp is the existing behaviour |
| Activate | ⚠ Weakest link. Longer gate than a free competitor's whole product |
| Engage | ⚠ Little reason to return between "shared it" and "match found" |
| Retain | Analytics + proposal status are the only real hooks |
| Expand | Untested — cards-per-identity has never exceeded 1.0 |
| Marketplace | 6–18 months later, after the account has gone quiet |
| Refer | Real but small; see C |
The cold start has no plan. The first ~500 profiles cannot come from the loop, because the loop needs profiles to start.
E. Consumer + My QR Setu architecture
The information architecture is right, and better supported than expected: /<slug> is already "a namespace root, not a page", and setu_card + qr_tools are already universal features granted to consumers.
One extension, taken once, unlocks it. The platform expresses a Consumer as a principal but not yet as an owner of a resource. Slug and media are two instances; users.avatar_media_id already FKs into a workspace-keyed table, so the schema is already inconsistent with itself.
Extend the class, not the instance: a
slugs(slug, owner_type, owner_id)registry for the namespace, and a nullable-pairCHECK (num_nonnulls(workspace_id, owner_user_id) = 1)for rows. The pattern already exists here —feature_grants_scope_target_matches_kind.
⚠ Two corrections to decisions recorded in this section
1. The identity page re-opens the enumeration hole the feature closes. Slugs are name-seeded, so /priya-sharma returning 200 vs 404 is an account-existence oracle over a name dictionary — and if it renders public profile data by default, the harvest prevented at the feature URL simply succeeds one level up. Because the slug is claimed at onboarding, this is the default state of the largest population on the platform.
Recommendation: claim the slug at onboarding as a reservation; render nothing by default; /<slug> must return an identical response whether unclaimed, claimed-unpublished, or private.
2. unique (owner_user_id) where status <> 'retired' forbids an ordinary family. A parent with two unmarried daughters must either retire a live proposal or create a second account — which violates this section's own rule "never solve a modelling problem by creating a second account."
Recommendation: keep "one active per subject", not per account, and let the account hold several subjects.
F. Consumer + Merchant + Enterprise
No contamination risk in the direction feared. Tier isolation is already three-way and derived from a TIERS array; orders.buyer_user_id is already nullable by design.
The real gap is the opposite: apps/web/src/tiers/ is admin, landing, merchant, public — there is no consumer tier on web, and web is the recipient surface the entire growth loop runs through.
G. Feature architecture
| Area | Verdict |
|---|---|
| Onboarding, principal model, entitlements | ✅ Reuse — the individual path already produces a correct consumer |
| Public destination, headers, PII posture | ✅ Reuse — order-status.tsx is the worked precedent |
| Slug ownership, media ownership | 🔧 Extend — one ownership decision, two instances |
| Vendor relationship | 🔧 Extend — saved_and_recent + consumerActivity stub already exist |
| Consent for a non-account subject | 🆕 Build — the feature's central legal object |
| Per-recipient access control | 🆕 Build |
| Moderation, takedown, person verification | 🆕 Build — and it is an operating cost with a named human |
| Server-initiated delivery | 🆕 Build — there is no push channel; all notification code is local scheduling |
track-card-event beacon | 🩹 Fix — wired and posting to a 404 |
| Merchant/enterprise model | 🚫 Do not touch |
H. Prioritisation
Decide now (cheap, and expensive to reverse): ownership extension · consent model · slug rendering default · one-active-per-subject.
Not now: everything else.
⚠ The engagement engine (§11) should not be built for one feature. CLAUDE.md forbids abstracting across things that do not exist. Build the biodata's events; extract an engine when a second consumer feature needs one.
I. Proactive experience
The philosophy is right and currently undeliverable: there is no server-initiated channel, so every nudge that would retain a dormant creator cannot reach them.
⚠ And several proposed nudges cannot be honest. "A photographer near your preferred location…" requires inferring an upcoming wedding — which the owner's own ⛔ boundary forbids. Any nudge must be derived from stored events the creator can see, or it is fabricated insight.
J. Marketplace flywheel
The ⛔ boundary does not break it. The flywheel never required the biodata to be in the marketplace; it requires the same account to browse it. Navigation, not data-sharing.
But the payoff arrives 6–18 months after the account goes quiet, and no lead object exists. Treat it as a reason the strategy is sound long-term, not as a Year-1 revenue line.
K. Monetisation
The incumbent charges ₹149 once. The proposal is ₹399–699 per year. That is 3–5× more, recurring, for a substantially similar capability — a challenge to the model, not a tweak.
Templates are commoditised at ₹0. Safety must be free. What can be sold: capability, convenience, reach, and assisted creation (human service, uncopyable by a free tool). Web-first conversion is forced by ADR-0002.
L. Major risks
- Sequencing — an unrepeatable deadline 17 days out, nothing shipped, the money loop unclosed.
- Duty of care — photographs and DOBs of young women, no moderation queue, no takedown path, no named grievance officer. ⚠ DOB is a core biodata field, so the platform acquires actual knowledge of minors by design and cannot claim ignorance.
- Differentiation — four of five MVP capabilities already free elsewhere.
- Activation — the gate is longer than the competitor's whole product.
- Channel conflict — bureaus are both the best channel and the party disintermediated.
M. Long-term vision
Coherent, and worth holding. One permanent consumer identity, many activatable experiences, a marketplace behind the same account. The proof metric is cards per identity > 1.0; until that moves, the identity model is a story rather than a business.
N. Recommended next steps, in order
- Reconcile with QRS-531 and QRS-527 before anything else. Either the park stands, or the owner lifts it deliberately. Do not proceed by omission.
- Ship Ganapati. 17 days, unrepeatable, and nothing has shipped yet.
- Run the incumbent as the experiment — zero developer-days. Source 12–15 real families through two or three vadhu-var suchak mandals, create their biodata on
paperprofile.in, and measure revealed behaviour: do families circulate the link or re-attach the PDF? do recipients open it? do they print it anyway for a melava? do subjects object once told a view counter exists? This tests the entire thesis without writing code, and nobody proposed it. - Take the four cheap decisions (E, H) while the experiment runs.
- Revisit after the merchant loop closes, with data instead of assumption.
⚠ The assumption all five lenses shared
Every lens assumed the biodata must be an account-based product, and none tested the frame. Every contested decision here — slug-at-onboarding, the namespace fight, the entitlement grant, the ownership extension — descends from that unexamined premise.
A link-first, account-optional biodata would dissolve most of them. That frame deserves an explicit hour before any of the four decisions are taken.