Lifecycle and horizontal expansion

🔵 Research. The most strategically important page in this section.

The question that produced it

The owner's own challenge, and it is the right one:

"Every acquired user here is not a long-term user, and until matchmaking — then how can this scale? Keep targeting new users every year? What are other horizontally scaling opportunities for monetisation?"

This is the correct objection and it should be answered before any code, because the answer changes the data model, not just the roadmap.

The problem, stated plainly

Marriage is a finite-duration use case. A person creates a profile, uses it actively for perhaps 3 to 18 months, gets married, and then has no reason to open a marriage-biodata product again.

A marriage-only model therefore has a permanent treadmill:

acquire single person → sell premium → they marry → they vanish → acquire again

That is a business, but it is not a compounding one. Year 2 starts from roughly the same place as Year 1, and every rupee of acquisition cost has to be re-earned annually against a shrinking addressable pool per cohort.

⚠ It is also worse than it looks, because the product's own success accelerates the churn. The better the matchmaking outcome, the faster the user leaves. Most products do not have a success-state that is also a departure-state.

The answer: the account is permanent, the card is temporary

The strategic shift is a single architectural principle:

Consumer Account ≠ Consumer Card

The account is permanent. Cards are use-case-specific and may be temporary.

CONSUMER ACCOUNT  (permanent, one QR, one identity)
   │
   ├── Personal Card          persistent
   ├── Marriage Card          temporary — retires on marriage
   ├── Wedding Card           event-scoped
   ├── Couple Card            begins where the marriage card ends
   ├── Family Card            expands the account
   ├── Professional Card      persistent, different lifecycle
   └── Event Cards            recurring

Marriage stops being the product and becomes the acquisition wedge. The user does not churn; their card retires while their account continues.

⚠ The QR is the part that makes this psychologically real. If the artifact a person shares is "my marriage QR", it dies with the use case. If it is "my QR Setu" and resolves to whichever cards are currently enabled, then after marriage they simply switch the marriage card off and the QR keeps working. You are no longer asking someone to "keep using our marriage app"; you are keeping their identity live.

⚠ This converges exactly with a rule CLAUDE.md already wrote, and that is worth noticing

The strategy above was reached from a commercial direction. This repo reached the same structure from a naming direction, months earlier:

"Everything card-shaped in the repo today is the Setu Card, and there is no second card product yet. Name as if there were: SetuCardTemplate / EventCardTemplate / VCardTemplate … Each card product gets its own contract when it arrives."

Two independent lines of reasoning arriving at account holds many card products, each with its own contract is the strongest signal in this whole research set that the shape is right.

But the same rule carries a warning that must not be skipped, and it is the hard part:

"Do not build a shared abstraction across card types that do not exist. An event card's blocks (date, venue, RSVP) share almost nothing with a Setu Card's, so a generic CardTemplate with a cardType discriminator would be the branch-on-type sprawl ADR-0021 D4 bans elsewhere."

The resolution — and this is the key distinction on this page

These are two different decisions, and conflating them is the trap:

Decision	When	Why
The ACCOUNT model — one permanent consumer identity, one durable QR, cards attached to it and independently retirable	Now, before any code	Structural, cheap while nothing exists, and effectively impossible to retrofit once a marriage card is the account. This is what stops the dead-end.
The CARD abstraction — a shared schema, renderer or template system spanning card types	Not until the second card type actually ships	Speculative generalisation across one real example. This is how the prototype acquired an Ad Manager and an in-house billing engine.

Make the account decision now. Refuse the abstraction until there are two real cards to generalise from. A marriage card and a hypothetical wedding card are not two examples; they are one example and a plan.

The horizontal set, ordered by how naturally it follows

Not a roadmap. A ranked list of candidates, with my read on each:

Horizontal	Follows from	My assessment
Couple card	marriage concludes	Strongest. Zero acquisition cost, emotionally natural, begins precisely where the marriage card retires.
Wedding invitation	engagement	Strong and immediate. Well-understood paid category (RSVP, guest list, schedule, venue), and Indian weddings already spend here.
Anniversary / memories	1 year later	Recurring revenue trigger — the rarest thing in a one-shot product. An annual, dated, emotionally-timed reason to return.
Family card	children, household	Expands one account into several people. Good retention, unclear willingness to pay.
Personal / link-in-bio	always	Persistent, low-value alone, but it is what keeps the QR meaningful between life events.
Professional / resume card	career	Largest long-term market and the weakest adjacency. A different audience, different competitors (LinkedIn, Canva), different buying moment. Genuinely a separate product decision.
Vendor marketplace	post-engagement	Highest ceiling, entirely different business (supply acquisition, quality control, payments). Explicitly not MVP, and I would go further: not Year 1.

What this does to the commercial model

The source analysis's own comparison, which I think is directionally right:

	Marriage-only	Identity model
Revenue per user	~₹499, once	₹3,500–₹5,000 over ~5 years
Acquisition	must repeat annually	amortised across the lifecycle
Justifiable CAC	very low	materially higher
Year 2	starts over	compounds

⚠ Treat those LTV figures as illustrative, not forecast. They assume the user buys at four or five separate life stages across five years, with no churn between them, in a product that does not yet exist. The shape of the argument is sound — multi-card LTV beats single-card LTV. The magnitude is unvalidated, and the honest version is that a second paid card type is the thing to prove, not the seventh.

The KPI change is the part I would adopt immediately, because it is free and it changes behaviour:

• Not "number of marriage profiles".
• Instead: active consumer identities and cards per identity.

The second number is the whole thesis in one metric. If it never exceeds ~1.0, the identity model is a story rather than a business, and you will know early.

My assessment

The strategic shift is correct, and the churn objection that produced it is the most valuable single contribution in the source material. A marriage-only product has a structural ceiling that no amount of growth engineering removes.

Three cautions, in order of how much they would cost:

1. Scope explosion is the live risk. The follow-up conversation lists roughly a dozen card types. Its own advice is right — "Don't launch marriage + resume + birthday + family + wedding + professional + student + creator + events all at once" — but a portal page that lists them all makes each look approved. They are not. One wedge, one proven second card, then reconsider.
2. The professional/resume horizontal is a different company. It shares an account model and nothing else: different users, different competitors, different acquisition. Listing it beside "couple card" implies an adjacency that is not there.
3. The identity framing raises the duty-of-care stakes rather than lowering them. A permanent consumer identity holding marriage, family and children's details is a materially more sensitive asset than a temporary biodata page. Everything in Risks and duty of care gets harder under this model, not easier, and the retention benefit is precisely what creates the concentration of data.

What I would actually do: take the account decision now (it is cheap, structural and irreversible-if-missed), build only the marriage card, and pick exactly one horizontal — couple or wedding — as the proof that cards-per-identity can exceed 1.0. Everything else stays on this page as a candidate, unbuilt, until that number moves.