CELABE.

The problem

Wedding planning is a co-ordination disaster. The average couple stitches together a planner's spreadsheet, a WhatsApp group with twenty vendors, a Pinterest board that grows by the day, and three physical notebooks. Vendors quote the same couple in different formats. Guests show up with no clear timeline. Photos from the event are scattered across thirty phones and never seen again. The planner — usually one heroic family member — burns out by week six.

CELABE was built to be the single tool that holds the wedding together. One app the couple, the planner, the vendors, and the guests can all open. AI assistance for the planning load (timelines, vendor shortlists, budget sanity), a real marketplace where vendors can be booked instead of just contact-bombed, and a viral QR-coded photo-sharing flow so the actual event memories live somewhere other than 30 random camera rolls. Three platforms, four user types, one product.

Constraints

• Founder-track economics. We were building 0-to-1 with a small team. Every architectural choice had to optimise for shipping speed and revisit-cost, not theoretical scale. Wrong calls in this phase cost weeks; right calls compound.
• Three platforms with shared logic. iOS, Android, and web all need the same vendor search, the same RSVP flow, the same payment surface. Different code paths per platform = three places for a feature change to drift.
• Trust matters more than features. Customers are spending months of household income through this app. A flaky payment, a missed RSVP, or a lost photo album doesn't just lose us the customer — it loses us their entire family network. The bar for "ship" was higher than for a dev-tool product.
• The marketplace has two-sided risk. Bringing on vendors before couples and the marketplace looks empty; bringing on couples before vendors and they bounce. The product had to feel useful even on day one with thin supply.

Architecture

One TypeScript codebase across all surfaces

CELABE is built on React Native (Expo) for iOS + Android and Next.js 15 for the web — both consuming the same typed API client generated off the backend schema. Business logic (vendor search ranking, timeline rules, budget calculator) lives in a shared @celabe/core package imported by every surface. UI components are a thin platform-specific layer over the same primitives.

NestJS backend with modular boundaries

The API is a NestJS server organised by domain: users, weddings,vendors, marketplace, payments, media, rsvp, llm, analytics. MongoDB is the primary store — wedding data is deeply nested (events, sub-events, vendor bookings, guest lists, dietary preferences, seating charts) and the schema flexibility kept iteration cheap during the founder phase.

ML-powered planning

The planning AI does three things, all gated behind clear UI. Vendor matching ranks vendors by location, style match (extracted from the couple's shortlist photos), price band, and review sentiment. Timeline generation turns the wedding date and selected events into a backwards-planned schedule with anchor checkpoints (venue lock, save-the-date, final RSVP cutoff). Budget sanity flags line items that diverge from cohort norms.

Every AI call goes through a single llm module with prompt caching on the system prompt and structured output. The product never auto-acts on AI output — every AI suggestion is a card the user approves, edits, or dismisses. That stays true even when latency would let us be more aggressive — the trust ceiling matters.

Viral QR photo-sharing

The single most-used feature so far is the QR photo album. Each event gets a unique QR code printed on the invite or displayed at the venue. Guests scan, land in a permission-scoped upload page that doesn't require an account, and drop their photos straight into the couple's shared album. The couple — and invited family members — get the full collection, deduplicated and chronologically sorted, after the event. Behind it: AWS S3 for storage, Lambda for image transcoding via MediaConvert, CloudFront for delivery, and a small ML pass for face-dedup grouping.

Payments + vendor marketplace

Stripe and Razorpay both wired in for India + international vendor payouts. Vendor marketplace is a commission model — a fraction of each booked engagement. Payouts run through a NestJS background job that reconciles bookings with completed events and triggers vendor settlement after a holdback period.

What I built

• The full technical architecture — three surfaces, one backend, a shared type system, and the deployment pipeline that lets the team push to staging and prod without manual steps.
• The core data model — events, sub-events, vendors, bookings, guests, RSVPs, payments, media albums — designed for the next two years of feature additions, not just MVP.
• The founding engineering culture — code review cadence, branching model, observability (Sentry, PostHog), CI/CD via GitHub Actions, and a Claude Code agentic dev loop wired into the daily build / test / ship rhythm. Release cycles compressed from weeks to hours.
• The AI integration layer — prompt-cached LLM router, vendor-matching pipeline, timeline generator, budget sanity checker. Every AI surface is a card with a human approve / edit / dismiss step.
• The QR photo-sharing flow end-to-end — invite-side QR generation, guest-side permissionless upload, S3 + Lambda + MediaConvert + CloudFront pipeline, ML-powered dedup and grouping.
• The Stripe + Razorpay payments stack, marketplace commission accounting, vendor payout reconciliation jobs.

Trade-offs

• React Native + Next.js vs. true cross-platform shared rendering. Expo + Next.js gives two truths — the mobile UI tree and the web UI tree. We sacrificed code-shared UI to keep platform ergonomics native. Business logic is shared via @celabe/core; only the rendering layer forks. We'd revisit Expo Web later if the duplication ever started costing real velocity.
• MongoDB vs. PostgreSQL. Same trade-off Phiny faced. Mongo wins for nested-document flexibility during the founder phase; PG wins for analytics. With CELABE's deeply nested wedding schema, Mongo was the right call for now. The analytics layer will eventually need a Postgres aggregator alongside.
• AI as suggestion, never action. We deliberately don't let the AI auto-book vendors, auto-send invites, or auto-schedule. Every AI-generated suggestion is a card the user has to approve. That sacrifices some "magic" for a much higher trust floor — non-negotiable in this category.
• Marketplace cold-start. We seeded the platform with high-quality vendors before launching to couples — slower than the "both sides at once" approach, but it meant day-one couples saw a live, useful marketplace instead of an empty grid.

Outcome

CELABE is live on the App Store and Play Store, with celabe.com as the web surface. We're the platform a multi-market customer base now plans their wedding through. Release cycles run hours rather than weeks; the engineering culture compounds. Every architectural choice — the typed monorepo, the AI-as-suggestion pattern, the QR photo-sharing pipeline — is paying back in velocity now that the team is building features rather than infrastructure.

CELABE is also the project where I locked in founder-mode engineering for myself: ship fast, choose the boring stack at the boundary and the leverage stack in the middle, and keep AI as the feature multiplier rather than the load-bearing wall. The same playbook — shared types, edge-fast backend, AI as suggestion, end-to-end ownership across web + mobile — is what I now reach for whenever a 0-to-1 product needs to ship in months, not years.