Garden Events

Overview

Garden Events is a speculative product we designed for the small independent venues that host weddings, reception parties, birthdays, and engagement functions in Tier-2/3 Indian cities. It's not a shipped product; it's a design and architecture we'd build out for a real venue owner. The brief: what would venue management software look like if you designed it for a 200-seat garden that books 40 events a year — not a 500-seat 5-star banquet hall.

The problem

The independent function hall / garden venue is a common business in India — every mid-size town has 20 of them, most owner-operated, most booking through word-of-mouth and phone calls. The recurring pain points are painfully universal. First: double-bookings happen 2-3 times a year, caught only when two families show up on the same Saturday — catastrophic for brand and refunds. Second: deposit collection is messy — the customer books, promises to pay the advance 'tomorrow', and by the time the venue chases it the date is already held for someone else. Third: catering head-count confirmation is a last-minute panic — the cook needs to know if it's 180 or 220 plates, and the customer 'will confirm by Thursday'. Existing venue software (Honeybook, Dubsado, even Petpooja Events) is priced in USD and configured for Western wedding-planner workflows. Nothing fits a ₹40,000-a-booking garden in Karimnagar.

What we built

• •Built the owner surface as a web app (not mobile) because the owner is usually working from a desk with a laptop — a calendar is easier to read on a 15-inch screen than a 6-inch phone. Mobile works fine for glancing; desk work gets desk tools.
• •Calendar UI as the home screen: month view with each event colour-coded by status (tentative / confirmed / deposit-paid / complete). Click a date → event detail with customer info, package, headcount, advance paid, catering notes.
• •Spec'd a state machine for the booking lifecycle: tentative → deposit invoice sent → deposit paid → week-of confirmation → day-of coordination → closed. Firebase Functions fire WhatsApp messages at each transition so the owner doesn't have to chase.
• •Razorpay integration for deposit collection — customer taps the WhatsApp invoice link, pays via UPI, deposit marks as paid in the owner's calendar in realtime. The 'chase the deposit' problem solves itself.
• •Morning-of coordination surface: day of the event, owner opens a single screen with customer contact, package details, catering head-count (confirmed or estimated), setup checklist. One-page summary, no navigation.

Key features

• Month-view calendar with colour-coded event statuses
• WhatsApp-based customer touchpoints — no portal, no app, no signup
• Razorpay deposit invoice — UPI link in WhatsApp, customer taps, pays, owner sees it
• Automatic WhatsApp reminders (deposit due, week-of confirmation, morning-of)
• Morning-of coordination screen — one page, all the day's info
• Double-booking prevention — same date = hard block, owner overrides explicitly
• Package presets (birthday, reception, engagement) with editable per-booking
• Monsoon / muhurat / peak-date pricing notes stored per-date

Results

Concept, not shipped. What exists: a Figma design file for the owner's web calendar + event detail + deposit flow, a React prototype wired to Firestore with mock bookings, a Razorpay test integration, a documented WhatsApp Business API plan, and this case study. If you own a garden venue or function hall in India and the double-booking / deposit-chasing problems are eating your week, talk to us about a 4-week pilot.

A concept design for a two-surface system: a web calendar the owner manages (dates, packages, catering head-counts, deposit tracking) and WhatsApp-based customer touchpoints (booking confirmation, payment reminders, morning-of coordination). No customer app, because nobody books a garden venue twice a year on an app they installed once.

What we learned

• →The 'don't make the customer install anything' principle from Clinic Queue applies even harder here — a customer books a venue once or twice a lifetime, they have no muscle memory for your app.
• →Desk work deserves desk tools. The owner is on a laptop most of the day; designing mobile-first for them would have been a misread of their actual workflow.
• →Scope discipline kept the product honest. Saying no to 'public venue website' and 'lead capture' meant we solved the three real pains deeply, not five pains shallowly.

Stack