We Built Trust Before We Built a Pricing Model — Here’s What That Taught Us

When most people think of the matrimony industry in India, they picture a business model that hasn’t changed in twenty years: charge for registration, charge more to see contact details, charge again to “boost” a profile. It’s a model built around extracting money from people at the most emotionally vulnerable moment of a major life decision — finding a life partner.

We built MarathiVivah, a matrimony platform for the Marathi community, on a different premise: whatever we eventually charge for, it will not be for the things that make a platform safe to use. Contact details, photo privacy, and identity verification were never going to be paywalled features. We’re currently free to join and use — that will evolve — but the trust and safety architecture we built was deliberately designed to stand independent of however we end up monetizing. That separation ended up shaping almost every early product decision we made, and taught us more about trust than any growth playbook could have.

## The insight that didn’t need a spreadsheet to validate

The idea didn’t come from market research. It came from watching how many Marathi families were still relying on word-of-mouth, community WhatsApp groups, and expensive traditional matchmakers — not because digital matrimony platforms didn’t exist, but because the existing ones didn’t feel like they were built *for* this community, or built with their safety in mind.

Two problems kept surfacing in conversation after conversation:

**Photos were public by default.** Anyone — logged in or not — could view and download a woman’s profile photo on most matrimony sites. In an era where AI-based photo morphing tools are trivially accessible, that’s not a minor UX oversight. It’s a real safety risk, and it disproportionately affects women.

**Trust was assumed, not earned.** A profile with a name and a phone number looked “verified” enough for most platforms. There was no mechanism to confirm someone actually was who they claimed to be, and no way to have a real conversation with someone before handing over a phone number to a stranger.

Neither of these is a monetization problem. They’re product and safety problems. That reframing is what set the direction for everything after — and it’s why we made a rule early on that we still hold to: figure out how to make the platform safe first, and figure out how to sustainably charge for it as a separate, later decision.

## Separating “how we make money” from “what’s behind the paywall”

We didn’t launch with pricing figured out, and we’re still working through what a sustainable model looks like. What we did decide early, and haven’t revisited, is *what monetization will never touch*: contact details, safety mechanics, and identity trust will not be the thing you pay to unlock.

That’s a deliberate constraint, not an accident of being early-stage. Platforms that profit from unlocking contact or visibility have a built-in incentive to make you want to unlock it — sometimes by inflating urgency, sometimes by under-delivering on the free experience so the paid one looks necessary. Ruling that lever out entirely, permanently, forces monetization to come from somewhere that doesn’t compromise the reason people trust the platform in the first place. We haven’t fully solved what that “somewhere” is yet. But we know what it isn’t.

## Building safety mechanics instead of buying trust badges

Because contact and safety were never going to be behind a paywall, we had to solve the actual trust problem directly, not paper over it with a pricing tier. A few decisions stand out in hindsight as the ones that mattered most:

**Photos are blurred and watermarked for anyone not logged in.** Full-resolution, unwatermarked photos are only visible to registered members — and even then, only once mutual interest is established for certain interactions. This alone eliminates the most common vector for photo scraping and misuse.

**Login is OTP-based, not password-based.** This wasn’t just a UX choice. Password reuse across sites is endemic, and a single breached matrimony database with reused passwords becomes a skeleton key to someone’s email or banking apps. Removing passwords from the equation removes that entire risk category for our users.

**Contact details are never unlocked unilaterally.** Sending interest, or a chat request, doesn’t reveal a phone number. Only mutual acceptance does. It sounds like a small workflow detail, but it changes the emotional experience of the platform entirely — no one can be contacted by someone they haven’t agreed to hear from.

**Voice and video calling happens before phone numbers are ever exchanged.** This was one of our more counterintuitive bets: build in-app calling as a core, no-cost-to-use feature rather than something reserved for later monetization, specifically so people could verify who they were talking to before ever sharing a personal number. It turns “is this person real” from a leap of faith into something you can actually check.

**Government ID verification is optional, not mandatory — for now.** We resisted the temptation to make ID verification a hard gate at launch. Mandatory verification sounds safer on paper, but it also raises the barrier to entry and can quietly exclude people who are perfectly genuine but hesitant to upload identity documents on day one. Making it optional, with a visible “Verified” badge as the reward, let trust build gradually and let the market tell us how much it mattered — it mattered a lot, which is useful signal for what comes next, including for verification possibly becoming mandatory down the line.

## What this taught us about building for underserved communities

The broader lesson wasn’t really about matrimony platforms, or even about monetization sequencing. It was about what happens when you build specifically *for* a community instead of building a generic product and hoping a community adopts it.

Generic products optimize for the median user. Niche communities — a specific caste, a specific language, a specific region — have specific fears, specific social dynamics, and specific reasons the median solution doesn’t feel safe or relevant to them. The Marathi-speaking community we built for cares about caste and sub-caste nuance in ways a generic Indian matrimony platform doesn’t model well. Families care about horoscope matching details a Western-style dating app would never surface. And the safety concerns around photos and contact information aren’t abstract — they’re shaped by real stories people had heard from someone they knew.

You can’t discover those specifics from a spreadsheet or a generic user-research script. You discover them by being close enough to the community to hear what actually worries people, and then being willing to make product decisions — like ruling out an entire category of monetization before you’ve even solved monetization — that a purely growth-optimized team would never choose.

## Where we go from here

None of this is finished. Verification, safety tooling, and trust mechanics are never “done” — they’re a continuous response to how people actually try to misuse a platform, which evolves as fast as the tools available to bad actors do. Pricing isn’t finished either; we’re still working out what a sustainable model looks like, and it won’t stay free forever. But the constraint we set at the start stays fixed regardless of where pricing lands: for a decision as significant as choosing a life partner, trust isn’t something you should ever have to pay to access. Whatever we charge for, it won’t be that.

—

*MarathiVivah is a matrimony platform for the Marathi community, currently free to join, with privacy-first photo protection, OTP-based login, and no-cost in-app video calling built in from day one. Learn more at [marathivivah.co.in] ( https://www.marathivivah.co.in ).*