Monetisation

🔵 Research. Assessment of the proposed revenue model against the ₹50 lakh Year-1 target.

Read Reference landscape first — it removes one of the four proposed layers entirely.

⚠ The binding platform constraint, which the plan does not account for

ADR-0002 (Accepted) makes the native apps free companions with NO in-app purchase UI and NO purchase call-to-action, under Apple guideline 3.1.3(d). CLAUDE.md restates it as a standing rule: a proactive upsell inside the iOS app is "a store-review risk, not just a product choice", and plans convert via web, never an in-app path.

The proposed model is a mobile-first consumer funnel with in-app upgrades. Those are incompatible as stated, and the consequences are concrete:

The plan assumes	What ADR-0002 permits
User creates profile in app, hits a premium feature, upgrades in app	Discovery and the locked state are fine. The purchase is not.
"Upgrade to Pro" CTA at the moment of intent on iOS	❌ Not on iOS. Web only.
Frictionless conversion driving the 8–10% rate	⚠ Every iOS conversion crosses to a browser, and every hop costs conversion.

This is not a blocker, it is a design input, and the platform already has the pattern: the fifth rule requires the capability to be discoverable and locked everywhere, with the action differing by surface — a real CTA on web, and on native a statement that plans are managed on the web (home.plan.onWeb already exists). Android is more permissive than iOS, so a per-surface split is possible.

⚠ But the revenue model must be built on the web-converted rate, not the in-app rate, and the plan's conversion assumptions were almost certainly formed imagining the latter.

The conversion assumption is the load-bearing weakness

The plan's own worked example:

100,000 registered → 40,000 published → 8,000 buy ₹499 Premium (₹39.9L) + 2,000 buy ₹499 assisted (₹10L) = ₹49.9L

Stated as rates:

• 20% of published profiles convert to paid
• 8% of registered users convert to paid
• 10% of registered buy something

For an Indian consumer freemium product with a browser hop in the middle, 1–3% of registered is the normal band and 5% is strong. At 3% the plan needs ~334,000 registered users, which its own §12 acknowledges before the model quietly proceeds at 8%.

⚠ The plan's arithmetic is correct; its inputs are optimistic. ₹50L is not mathematically wrong, it is conditionally right — conditional on a conversion rate roughly three times typical.

A sharper way to size the ambition

Matrimony.com reported roughly ₹455.8 crore revenue against about 1 million paid subscriptions (FY2025, cited in the source analysis) — an ARPU near ₹4,500.

The target here is 10,000 paying users at ₹499. So:

₹50 lakh means capturing ~1% of the incumbent's entire national paid subscriber base, in one state, at ~11% of their price per user, in year one.

That framing is less comfortable than "0.008% of Maharashtra's population" and it is the more honest one. It also points at the real strategic answer: price is the problem, not just volume. At ₹499 you need ten thousand payers. The lifecycle model — multiple paid cards per identity over years — is what makes the ARPU gap closeable without needing matrimonial-portal scale.

The four proposed layers, reassessed

Layer	Proposed	Assessment
1. Premium templates ₹99–₹499	paid	❌ Drop. Competitors give 50+ templates free, no sign-up, PDF and Word, eight languages. Selling templates here is worse than not selling them.
2. Premium privacy ₹199–₹599/yr	paid	⚠ Split it. Safety must be free — a model where the free tier is unsafe converts a duty of care into a price list (Risks). What can legitimately be paid: convenience and reach — more concurrent share links, longer history, richer analytics, scheduled expiry, multiple languages. Not "protected sections".
3. Premium profile ₹499–₹999/yr	paid	✅ The defensible core. It sells exactly what no competitor offers: the living link, control, status, analytics, video/voice, custom URL.
4. Assisted creation ₹299–₹999	one-time	✅ Strongest near-term revenue, and structurally uncopyable by a free generator because it is human service. ⚠ But it is a services margin, not software margin: real turnaround-time expectations, quality variance and per-unit human cost. 2,000 units is an operations plan, not a feature.

The plan's own §25 warning is right and should be kept: do not nickel-and-dime (₹99 template, ₹149 photo, ₹99 privacy). One meaningful Premium, one Assisted service.

What is missing from the revenue model

• GST. Digital services attract 18%. On ₹50L gross that is roughly ₹7.6L if inclusive. The plan treats ₹50L as net.
• Payment costs. Razorpay MDR applies to every transaction. ⚠ Per CLAUDE.md's standing rule, never hardcode or assume a specific rate — record actuals.
• Store fees. Web-first conversion is what makes these 0%, which is ADR-0002's commercial point. Any drift toward in-app purchase reintroduces 15–30%.
• Refunds and failed payments, in a low-trust, first-purchase consumer category.
• Support cost, which for assisted creation is the product.
• Seasonality. ₹4.17L/month is an average, not a shape.

A realistic net on ₹50L gross is plausibly ₹40–42L before any operational cost.

My assessment

₹50 lakh is a legitimate stretch target and a poor plan of record. The source analysis reaches the same conclusion in its §34 and then sets ₹20–30L as base, which I think is right.

What I would change, in priority order:

1. Move the paid line. Templates free and plentiful; safety free; sell capability, convenience and reach. This is forced by the competitive landscape, not a preference.
2. Design the funnel for a web-completed purchase from the start — because ADR-0002 requires it on iOS, and retrofitting a cross-surface upgrade path into a mobile-first flow is exactly the kind of late correction this repo keeps recording.
3. Lead with Assisted Creation. It monetises the least app-comfortable users, needs the least product surface, cannot be copied by a free tool, and produces revenue while the viral coefficient is still being measured. It is the fastest honest rupee here.
4. Underwrite the plan at 3% conversion, not 8–10%. If 8% arrives, that is upside. Building the operating plan on the optimistic rate is how a stretch target quietly becomes a commitment.
5. Make cards-per-identity the commercial KPI rather than paying users, per the lifecycle model. It is the only number that changes the ARPU ceiling rather than the volume requirement.