Building Kalyra, a Wedding Marketplace for Kerala

Anyone who has planned a wedding in Kerala knows how it goes. You want a photographer for a Sunday in January, so you find ten names on Instagram, call them one by one, and most of them say the same thing: "Let me check and get back to you." Some do. Many do not. The ones who reply send prices on WhatsApp in completely different formats, with different things included, and somewhere in a family group chat a relative is asking whether the hall has been booked yet.

That is the problem I have been working on. It is called Kalyra, and it is live at kalyra-prod.vercel.app.

What Kalyra is

In Kalyra's own words: venues, photographers, makeup artists, caterers and every other vendor across Kerala, with availability the vendor has actually confirmed.

It is a marketplace with three sides to it:

• Couples search for vendors by their wedding date, send one structured enquiry instead of a dozen calls, compare quotes that all follow the same format, and book and pay the advance in one place. Everything lives in a wedding workspace with a budget, a checklist and a countdown.
• Vendors get a Vendor Studio to run their business: leads with the date attached, availability, packages, quotes, bookings, payments, their team and insights about what couples are looking for.
• Admins get a console to verify vendors, oversee bookings and payments, handle disputes and keep an audit trail of everything.

It is launching first in Central Kerala: Ernakulam, Thrissur, Kottayam, Alappuzha and Idukki.

The one idea: be honest about availability

Most wedding sites have a little green "available" badge that means nothing. Nobody checked. The vendor set up a listing two years ago and the badge has been green ever since.

Kalyra's whole design is built around not doing that. A vendor is only shown as available on your date when they have explicitly confirmed it, recently. Every other case gets an honest label instead:

• Available. The vendor confirmed this date recently. Confirmations expire, so this never goes stale.
• Tentative. Their calendar looks open, but they have not confirmed it yet.
• Confirmation required. We do not know yet. Ask them in one tap and they will tell you.
• Unavailable. Booked or blocked by the vendor.

Each result also says why it has that status, in plain words. And confirmations expire on purpose. Try it below: let two weeks pass and see what happens to a confirmation nobody renewed.

Vendors who have confirmed always rise to the top of search results, so there is a real reason for them to keep their calendar honest.

Not every vendor works the same way

This was the most interesting modelling problem. A wedding hall and a wedding photographer do not have the same kind of "availability" at all.

A hall can host one wedding per slot. A photography studio with two teams can cover two weddings on the same morning. A makeup artist takes a number of clients per day. A wedding car company has six cars, not six calendars. So Kalyra has four availability modes, and each vendor category uses one of them:

1. 01
   Venues and stages: one booking per slot. A hall, a melam or an officiant serves one wedding at a time. Morning muhurtham and evening reception slots are booked separately, so an evening can still sell when the morning is taken. A main hall and a garden lawn each get their own calendar.
2. 02
   Teams and crews: capacity. Photographers, decorators and caterers often cover more than one wedding a day. The vendor sets how many teams they have, and Kalyra keeps taking bookings until they are all out. Two teams means two weddings on the same muhurtham, and the third couple sees them as busy.
3. 03
   Artists: appointments. Makeup and mehendi artists set their appointment slots and how many clients they can take in a day. A bride at dawn and a reception look in the evening can share a day.
4. 04
   Rentals and fleets: inventory. Wedding cars, homestay rooms and jewellery sets are counted, not scheduled. Each booking takes one unit from the stock for that date.

Under the hood, all four become the same thing: a vendor has resources (a hall, a team, an artist, a set of cars), each with a capacity, and every hold and booking is written to one shared ledger against those resources.

The couple's side

Once a couple finds vendors they like, the flow is four steps: search by your date, enquire once, compare real quotes, book and pay securely.

The enquiry carries the date, location, guest count, budget and what they need, so the vendor never has to ask the same five questions again. Vendors reply on Kalyra, with WhatsApp updates if the couple opts in.

Quotes are where I spent a lot of care. Every quote has the same structure: line items, taxes, payment milestones and cancellation terms, all up front. If a vendor revises a quote, it becomes a new version, and the old one stays visible. Nothing changes quietly.

When the couple accepts, the date is held for them while they pay the advance on a hosted checkout, so nobody else can grab it mid-payment. The booking only confirms after the payment is verified. The workspace then keeps the budget up to date on its own: estimated, quoted, booked, paid and refunded, driven by the bookings themselves rather than a spreadsheet.

The promise to couples fits in one line, and it is on the homepage: your date is held while you pay, your terms are locked when you agree, and your money comes back if a booking cannot be kept.

The vendor's side: the Vendor Studio

I did not want vendors to feel like they were filling in forms for a marketplace. The Vendor Studio is meant to be a genuinely useful tool for running a wedding business, even for bookings that did not come from Kalyra.

The Today page is the first thing a vendor sees: leads waiting, this week's events, money due in the next fortnight and profile views, with today's jobs underneath. "Your day, before you open WhatsApp."

From there, a vendor can:

• Confirm availability on a calendar, and get a regular nudge to check in so their open dates do not silently go stale.
• Work through leads, each with the couple's date, location, guests and budget, and reply, confirm and quote in one place.
• Keep one calendar for Kalyra bookings, the ones they take themselves, and blocked dates, with Kerala's peak wedding dates marked.
• Track bookings and payments from advance to final balance.
• Manage their team, assign crew to events, and follow task templates for their trade. A caterer gets "lock final headcount" five days out; a photographer gets reminders through to delivering the album.
• See insights: views, enquiries and bookings over time, why leads were lost, and which dates couples searched that the vendor has not confirmed yet.

The admin side

Behind it all is an Admin Console. Every vendor listing is reviewed before it goes live, and verified vendors get a badge couples can trust. Admins see a health board of vendors, can leave notes and messages, approve changes, look after bookings and payments, set Kerala's peak dates, run reports and export data. Staff can have different roles and be limited to certain districts, and every important action is written to an audit log.

How it is built

This is the part I am quietly proudest of, because none of it shows on screen but all of it matters when real money and real wedding dates are involved.

Kalyra is a modular monolith: one Next.js app, but with all the business rules living in plain TypeScript services (search, availability, enquiries, quotes, bookings, reservations, payments, notifications, admin) that pages and server actions simply call. Every change runs on the server inside a database transaction.

A few of the decisions I care about most:

• No double bookings, enforced by the database. Reserving a date locks the resource, clears out expired holds, checks blocks and capacity, and only then writes. For exclusive resources like a hall, Postgres itself has an exclusion constraint, so two overlapping bookings physically cannot be saved, even if two couples press pay at the same instant.
• Bookings confirm only after payment is truly verified. That means a verified webhook, a server-to-server check with the payment provider, and a successful reservation, all in one transaction. If someone pays but the slot was lost in the meantime, they get an automatic full refund.
• Terms that cannot be edited after the fact. Quotes are versioned rows, and database triggers block edits to sent quotes, accepted booking terms and the append-only logs.
• Row Level Security on every table, so a couple can only ever read their own data, and a vendor only theirs.
• Messages through an outbox. WhatsApp messages are written to an outbox inside the same transaction and sent afterwards, so a message is never sent for something that did not actually happen.

The stack is Next.js 16 with the App Router and server actions, React 19, strict TypeScript, Tailwind CSS 4, React Aria for every picker and select, Zod for validation, and Supabase for Postgres, auth and storage. Sign-in emails go out through Resend with Kalyra-styled templates. It is hosted on Vercel in the Mumbai region, with separate production and development environments.

For local development, the app runs an embedded Postgres (PGlite) that migrates and seeds itself on first start, so you can clone it and run it without creating a single account. The same embedded database powers the test suite: over a hundred unit and integration tests run against real Postgres with every migration applied. They cover things like concurrent booking attempts, duplicate webhooks, holds expiring and being re-acquired, refunds when a paid slot was lost, and making sure couples and vendors can never see each other's data. A Playwright test walks through the whole journey end to end.

How it looks

Indian wedding sites tend to be loud: pink, cluttered, discount banners everywhere. I wanted the opposite. Planning a Kerala wedding is noisy, and Kalyra should feel like the moment the noise stops, like holding a beautifully printed invitation.

The one decorative motif is the kasavu line: a thin double rule in almond gold, borrowed from the gold border of a Kerala kasavu saree. It frames the hero search, divides sections and underlines links on hover. Nothing else is decoration.

Type is two families from the Indian Type Foundry: Gambetta, a warm serif for headings, and Satoshi for everything functional. Colours are a deep brown, ivory, blush and almond, with a celebration red used sparingly for the main action. Photography leads, copy stays short, and each section opens with small spaced capitals like a bridal magazine spread.

Where it is now

Kalyra is an MVP, and I want to be upfront about what that means. Payments run on a sandbox provider for now, WhatsApp runs on a mock, and all the vendors you will see on the site are fictional sample businesses. The real payment integration is written but switched off until the provider, vendor terms and legal review are sorted out.

What is next: real payments, real vendors in the launch districts, calendar sync, invoices, and a proper domain of its own.

If you want to look around, the best place to start is the tour, which walks through the couple's workspace and the Vendor Studio with real screens.