Skip to content
Ajay B J

Case study · Full-stack · Fintech · Business & Product

Mane & Oggarane

Restaurant ordering & customer-retention platform

A full-stack ordering site for a Karnataka-cuisine restaurant concept, built as a demo to offer small restaurants their own ordering, payments and retention channel. It covers menu to checkout to Razorpay to kitchen dashboard.

Open live demoTest payments only, no real orders
Status
Live demoPublic demo · Razorpay test mode only
My contribution
Product owner and builder: I defined the requirements and business rules, built it with AI-assisted development, and tested payments, refunds and delivery rules myself.
Tools
Next.jsSupabaseRazorpayGoogle OAuthVercel
How AI was used
Code was generated and refactored with Claude and ChatGPT. I wrote the specifications, made the architecture and business decisions, reviewed changes and ran the testing.

The business problem

Small restaurants rely on aggregator apps for online orders, which means paying commission and never owning the customer relationship. Without their own customer data they can't run repeat-order offers, loyalty or targeted promotions.

The idea: give a restaurant its own ordering website with payments, delivery rules, an owner dashboard and retention tools built in, then package it as a product I can offer to other restaurant owners.

What I built

  • Customer website with a responsive menu, categories, search and veg/non-veg preference
  • Google sign-in, with login required before ordering
  • Basket and checkout with a full order breakdown (items, delivery fee, discounts)
  • Razorpay payment integration with server-side payment verification
  • Payment webhooks and refund management
  • Order management and an owner dashboard: menu manager, kitchen orders, cooking → dispatch status
  • Customer order tracking and pickup support
  • PIN-code-based delivery eligibility and delivery-charge calculation
  • Coupons and a points-based rewards programme
  • Policy pages (terms, privacy, refunds, delivery) needed for payment-gateway onboarding

Architecture

How an order flows

  1. 1Customer

    • Browse menu
    • Google sign-in
    • Basket & checkout
    • Track order

  2. 2Next.js app (Vercel)

    • Server-side price & fee recalculation
    • PIN-code eligibility
    • Coupons & rewards
    • Order API

  3. 3Payments

    • Razorpay order
    • Checkout
    • Signature verification
    • Webhooks & refunds

  4. 4Data & ops

    • Supabase Postgres
    • Supabase Auth
    • Owner dashboard
    • Cooking → dispatch status

Screenshots

  • Bilingual (Kannada + English) home page

  • Menu with veg/non-veg filters, search and a live basket; prices are re-confirmed on the server

  • Owner "Control Room". Figures shown are demo test data, not real sales.

  • Loyalty rewards: points credited only after a verified, delivered order

Business rules I defined

  • Delivery only to a fixed set of PIN codes; outside them, pickup only
  • Flat ₹40 delivery fee for small baskets (subtotal up to ₹100), free above that
  • Prices, fees and discounts are always recalculated on the server, never trusted from the browser
  • Reward points are credited only after the restaurant marks a verified paid order as delivered
  • Razorpay stays in test mode, and no paid SMS/AI services are switched on, until explicitly approved

Technical challenges

  • Payment reliability: making payment confirmation idempotent, so a retried webhook or double click can't create duplicate orders
  • Refunds and rollback paths when a payment succeeds but the order step fails
  • Keeping client and server totals consistent once coupons, fees and rewards interact
  • Making a public demo safe to share: a test-mode banner, sample data and no real orders

How it was tested

Before calling the staging build approved, I ran a consolidated verification pass covering delivery fees, PIN validation, payments, refunds, idempotency and rollback behaviour. All payments use Razorpay test mode. The demo shows a banner saying no real orders are taken.

Where it stands, honestly

It's a working staging product and a convincing public demo, but not yet a production-ready SaaS. Before I'd onboard a real restaurant, the remaining work is payment-reservation clean-up and reliability, legal and launch readiness, retention workflows (repeat-order nudges and segments), and a repeatable client-onboarding process.

What I learned

  • My payments-ops background mattered most in the edge cases: verification, refunds and reconciliation are where real systems break
  • Writing business rules down before building saves rework, both for me and for an AI coding assistant
  • AI makes building fast. Testing, reviewing and saying no to scope creep is still on me.
  • A demo needs explicit guard-rails (test-mode banners, sample data labels) before you show it to anyone