Appearance
Problem analysis
🔵 Research. Not built, not approved, no ADR.
The problem, stated precisely
Indian marriage matching runs on a biodata document — a one-or-two page PDF or image carrying name, date of birth, height, education, profession, income, family details, community, and photographs. It is created once, then forwarded through WhatsApp: to parents, to relatives, to a marriage bureau, to prospective families, and onward from each of those.
Every property of that artifact is wrong for the job:
| Property of a forwarded PDF | Consequence |
|---|---|
| Immutable after sending | A job change, a new photo or a corrected detail cannot reach anyone who already has it. The stale copy keeps circulating. |
| Uncontrolled once shared | The sender cannot see where it went, cannot withdraw it, and cannot stop a copy being re-forwarded or saved. |
| All-or-nothing disclosure | Photographs, income and exact date of birth go to every recipient equally, including strangers two forwards away. |
| No feedback | The sender learns nothing: not who opened it, not whether anyone was interested, not whether it is even being circulated. |
| No status | A profile that has already found a match keeps circulating for months, generating dead proposals. |
| Formatting is a proxy for seriousness | Families judge on presentation, so people pay for design help on a document that will be compressed by WhatsApp anyway. |
The insight in the source analysis is correct and worth stating plainly: the sharing behaviour is not broken and should not be fought. WhatsApp forwarding is the distribution mechanism of Indian matchmaking and it works. What is broken is the artifact being forwarded. The product opportunity is to replace a dead file with a living page inside the same sharing behaviour, not to move the behaviour somewhere else.
That reframing matters commercially too: it means the competitor is not BharatMatrimony or Shaadi.com. Those are matching businesses — they find you a partner. This is a presentation and control utility for people who are already matching, mostly through family and community networks that no portal touches. Attacking pre-matrimony sharing behaviour rather than matchmaking itself is the defensible position.
The persona
| Who | A person of marriageable age, or more often their parent or sibling, assembling and circulating a biodata. |
| Where | Maharashtra first (source analysis). Marathi and English, with Devanagari rendering already supported by the token layer (fonts.deva, Noto Sans Devanagari). |
| Device | Creator on a phone. Recipients on anything, without installing an app. |
| Emotional state | Cautious. Sharing a daughter's photograph and date of birth with strangers is not a casual act, and the product's tone has to earn that. |
⚠ The creator is frequently not the subject. A father creating his daughter's profile is the common case, not the edge case. That single fact has consequences the source analysis does not draw out, and they are structural rather than cosmetic:
- Consent is a first-class object, not a checkbox. The person whose photographs and date of birth are published may not be the account holder. Any "family collaboration" feature is a multi-person consent problem before it is a sharing convenience.
- Account recovery, deletion and erasure requests may come from the subject, not the creator. The user-lifecycle work assumes the account holder is the data subject. Here they can differ.
- The subject may want it taken down when the creator does not. There must be an answer, and it cannot be "contact the account owner".
This is the most under-specified area in the source analysis and the first thing I would resolve.
What the product would be
A published, access-controlled page replacing the PDF, plus a private surface for the creator.
The recipient side (public, no account)
Opening a shared link lands on a server-rendered web page, no install, no login. This is not a preference; it is what the platform already mandates and what makes the growth loop possible at all (see Architecture fit).
Progressive disclosure is the core mechanic, and it is what a PDF fundamentally cannot do:
| Tier | Visible to | Contains |
|---|---|---|
| Open | anyone with the link | first name, age, city, education, profession, one photograph |
| Requested | recipient asks, creator approves | full name, family details, more photographs, community details |
| Private | never public | exact date of birth, contact number, income, address |
The point is not that everything is hidden. It is that the creator decides the boundary and can move it per recipient, which is precisely the control a forwarded file destroys.
The creator side (in the app)
- Build the profile once; edit forever, with every shared link reflecting the change.
- Share to WhatsApp with a deliberate, attractive preview.
- See who opened it, how often, and who asked for more.
- Approve or decline access requests.
- Mark status — active, paused, matched — and have every existing link honour it immediately.
- Retire it, which is the success state.
Where the rest of this feature is documented
The capability set and MVP cut, the proactive surface, and the design state were originally drafted on this page. They now live where they belong, so that each has one home and cannot drift:
| Capabilities and the five-capability MVP | Feature set |
| What the creator sees, and the proactive nudges | Analytics |
| Design state and what must be decided first | Design |
| The seven problems mapped to capabilities | Feature set |
My assessment
The problem is real, the reframing is correct, and the mechanism is sound. Replacing the artifact without moving the behaviour is the right strategic shape, and the progressive-disclosure mechanic is a genuine capability a PDF cannot answer at any price.
Three things make me cautious, in order:
- This is a duty-of-care product before it is a growth product. It handles photographs and identifying details of (often) young women, published by someone else, shared with strangers, and optimised for reach. Every risk in Risks and duty of care compounds with the growth loop rather than trading off against it — the better the viral mechanic works, the larger the exposure. The source analysis treats privacy as a paid feature tier. If the free tier's disclosure is unsafe, selling safety is not a monetisation strategy, it is a liability.
- It does not fit the platform model, and pretending otherwise is how the schema gets bent. See Architecture fit.
- The revenue model assumes a conversion rate and an upgrade path the platform cannot currently deliver. See Monetisation.
None of the three is a reason not to build it. They are reasons to decide four things before drawing a single screen, and to treat the ₹50 lakh figure as a stretch target rather than a plan, which the source analysis itself concludes.