The Indian wedding market is large, fragmented and coordinated almost entirely by hand. The opportunity is in the coordination, not in another place to browse vendors.
Estimates in the commentary behind this piece put the industry at roughly ₹3.75 lakh crore across more than ten million weddings a year. Treat the total as an order of magnitude; the segment mix matters more than the headline.
Discovery is solved, coordination is not
Couples already find vendors through social platforms and personal networks. What remains manual is everything after selection: schedules, dependencies, payments in instalments, family approvals and last-minute substitutions.
A directory monetises the moment of discovery, which is the cheapest part of the journey and the easiest for a platform to lose. Coordination is where the money and the anxiety actually sit.
Pick one failure in that chain and build for it properly. A product that reliably prevents one expensive mistake is worth more than a marketplace that lists everybody.
The segments behave differently
Component markets inside the industry have different ticket sizes, decision makers and digital readiness. The split below follows the source material and should be read as proportional, not precise.
| Market | Share of value | Design consequence |
|---|---|---|
| Tier-1 metropolitan | About 40% | Highest budgets and most vendors; the problem is coordination and approvals. |
| Tier-2 cities | About 35% | Fastest-growing; vendor quality varies, so verification carries the value. |
| Tier-3 and rural | About 25% | Price-sensitive and relationship-led; assisted, low-bandwidth flows required. |
A product designed for the first row will not transfer to the third without changing who operates it. Decide which row you are building for before choosing a business model.
Design for the family, not the user
The decision unit is several people with unequal authority and unequal comfort with software. Any tool that assumes one logged-in user will be used by one person on behalf of everyone, and will lose the audit trail that makes it trustworthy.
Who may decide, who may spend, who only needs visibility.
What cannot start until something else is confirmed.
Instalments, advances and refunds, with a record both sides accept.
What happens when a vendor fails, days before the date.
The fourth is the reason planners get hired. Build it first.
Four capabilities of a wedding coordination product: roles, dependencies, money and substitution.Payment structure deserves particular care. Advances are customary, disputes are common, and a shared, timestamped record is more valuable to both sides than an escrow feature nobody trusts yet.
Culture is a requirement, not a theme
Rituals differ by community, region and family, and they determine the schedule. A product that models a generic two-day event will be abandoned by the third meeting.
The ceremony list is not fixed. Let families define it.
Some slots are non-negotiable and set everything else.
Multiple locations running at once, with shared vendors.
Different invitations, access and logistics per group.
Hard-coding any of these excludes a large share of the market.
Four scheduling requirements: variable events, auspicious timing, parallel venues and guest tiers.Treating these as configuration rather than content is what lets one product serve several communities without rewriting it.
Decide what to test next
Take ten real weddings, document every coordination failure and what it cost, and build for the most expensive recurring one. Measure prevented failures, not signups.
Assess a wedding product against the mistakes it stops, since that is what a planner is paid for today.
Written by the studio, from work in delivery
