Appearance
Marriage Biodata Digital Identity
🔵 Research. Not built, not approved, no ADR, no design.
What it is, in one paragraph
A living, access-controlled destination that replaces the marriage biodata PDF people currently forward on WhatsApp. The creator builds it once and edits it forever; every already-shared link reflects the change. Recipients open it with no install and no account. The creator controls what each recipient can see, sees who opened it, and can mark the proposal closed so an old link stops generating calls.
What it is NOT
Stated first, because the first draft of this research got it wrong and the owner corrected it:
| It is not | It is |
|---|---|
| A new user persona | One feature available to the existing Consumer persona |
| A new account type | The same consumer account, with this experience activated |
| The consumer's identity | An experience attached to My QR Setu, which owns the identity and the slug |
| A separate marketplace | A participant in the existing marketplace |
| A matrimonial matching product | A presentation and control utility for people already exchanging proposals through family networks |
⚠ The last row is the strategic position. The competitor is not BharatMatrimony or Shaadi.com — they are matching businesses. This attacks the pre-matrimony sharing behaviour that no portal touches, which is why it does not need to win a matchmaking market to work.
Why this one first
- The behaviour already exists and works. WhatsApp forwarding is the distribution mechanism of Indian matchmaking. The product replaces the artifact inside that behaviour rather than relocating the behaviour, which is a far cheaper adoption ask.
- It is the correct first PII example. Consumer data is not indexed, and a marriage biodata makes that concrete: photographs, date of birth and family details, shared deliberately with chosen people and with no crawler anywhere near it.
- Every problem it solves is a property a file cannot have — see Problem analysis.
- It generates marketplace demand on a known timeline, which makes it valuable to the merchant side of the same platform, not only to consumers.
⚠ It is already promised publicly, and that changes the starting position
Measured 2026-08-28. This is not greenfield ideation. The live landing page already advertises the feature, in specific terms:
| Where | What it says |
|---|---|
landingContent.ts:875-876 | Card: "Marriage biodata" — "A biodata you can correct after you have already forwarded it, with photos and number hidden until you accept." |
landingContent.ts:959 | FAQ: individuals use a Setu Card as "a digital identity, a portfolio, a marriage biodata or an event invitation" |
landingContent.ts:676 | Retention loop: "…send the biodata…" |
PersonalSection.tsx:28 | "A biodata you can update after you send it" |
landingSeo.ts:77 | SEO keyword: "marriage biodata link" |
That section is wired and shipping: routes/home.tsx:35 imports it, :109 renders it on the index route, and deploy-web.yml deploys apps/web to devv.qrsetu.com on every push to develop.
Three consequences:
- The public promise is already specific, and the product must honour it — "correct after you have already forwarded it" and "photos and number hidden until you accept" are precisely capabilities 1 and 2 of the feature set. The marketing has already made the architectural commitment.
- The FAQ frames it as a use of the Setu Card, which is not what the architecture supports — a Setu Card requires a workspace. See Architecture.
- ⚠
landingSeo.tscarries "marriage biodata link" as an SEO keyword. That is legitimate for the marketing page and must never extend to a person's biodata. The PII rule draws that line.
State
| Design | ❌ Nothing in Claude Design yet (owner-confirmed 2026-08-28) |
| Schema | ❌ None |
| Routes | ❌ None |
| ADR | ❌ None |
| Research | 🔵 This directory |
| Decisions to take first | 4 — see Architecture |
The pages
| Page | What it answers |
|---|---|
| Problem analysis | What is wrong with a forwarded PDF, and who the user actually is |
| Research | What existing biodata tools do, and where the unoccupied position is |
| Feature set | The candidate capabilities and the five-capability MVP cut |
| User journey | Creator, recipient, and the retirement path |
| Privacy and security | PII, consent when the subject is not the account holder, DPDP, caste data, moderation |
| Analytics | What is measured, and the proactive surface it enables |
| Growth | The viral loop, its weak link, and channel ranking |
| Monetization | The revenue model against the ₹50 lakh target |
| Architecture | What is reused, what is extended, what is genuinely new |
| Design | Design state and what must be decided before requesting one |
Future extensions of this feature
Related life-event experiences belong under this feature, not at the top level of Consumer:
- Engagement card — the natural next step in the same journey
- Wedding invitation — RSVP, guest list, schedule, venue
- Couple card — begins where the marriage biodata retires
- Anniversary / memories — the recurring, dated return trigger
⚠ None is approved and none should be built alongside the first. The point of naming them is that the architecture should not make them expensive later — not that they are scope now.