Skip to content
Rathaworks

Case study · BookieeA three-sided bus booking marketplace where every seat sells once

Passenger app, operator portal, admin portal and website on one API — with seat holds that rule out double-booking, a visual bus-layout designer and a tracked refund queue.

Built at GravitonesDelivered
Industry
Travel & ticketing
Location
India
Timeline
3 months
Year
2026
Illustration of the Bookiee bus booking platform: passenger seat map and operator bus-layout designer
Illustration of the product. The client's production interface is confidential, so it isn't shown here — I can walk you through it on a call.

Results

apps on one API: passenger app, operator portal, admin portal and website
0
apps on one API: passenger app, operator portal, admin portal and website
screens across the mobile app and web portals
0+
screens across the mobile app and web portals
API endpoints behind one OpenAPI contract
0+
API endpoints behind one OpenAPI contract
of build as lead developer, June–September 2026
0 mo
of build as lead developer, June–September 2026

The challenge

What the client needed.

Bus travel is three businesses stitched together: the traveller who needs a seat they can trust, the independent operator who owns the buses and sets the fares, and the platform in the middle that verifies operators, takes a commission and handles refunds. Bookiee had the commercial idea and operator relationships, but no machinery to run it. The hard constraint: in travel, selling one seat twice isn't an apologetic refund — it's a passenger at a terminal at midnight holding a ticket that means nothing.

My role

Lead developer — architecture, API, passenger app, operator portal, admin portal and website

The approach

How I built it.

  1. 01

    Designed one Express + PostgreSQL API behind an OpenAPI contract, with generated React Query hooks and Zod schemas, so the passenger app and both portals can never disagree about data shapes.

  2. 02

    Made seat selection a claim, not a preference: chosen seats are held in Redis for a fixed window (10 minutes by default) and released automatically when a traveller walks away.

  3. 03

    Built operators a visual bus-layout designer — two decks, sleeper berths, doors and stairs, premium seats with their own price and seats reserved for women — saved as reusable templates.

  4. 04

    Treated Razorpay, not the phone, as the authority on payment: fares are computed on the server and a booking is confirmed only after the payment is verified; tickets arrive by SMS, email and push.

  5. 05

    Turned cancellations into a tiered, tracked refund queue and gave staff composable role-based permissions with an audit trail.

Key engineering decisions

The hard problems, and how I solved them.

The decisions that made the difference — each one a trade-off chosen on purpose.

  1. 01

    A seat can only be sold once

    Problem
    Popular routes sell in bursts — two travellers can both see the last free seat and both pay.
    Decision
    Atomic Redis seat locks with an expiry: picking a seat claims it, and an abandoned checkout releases it on its own.
    Outcome
    Double-booking is prevented by design instead of being cleaned up by support.
  2. 02

    No two buses are the same

    Problem
    Sleepers, two-deck coaches and women-only seats don't fit a grid — a rigid template would turn good operators away.
    Decision
    A layout designer with decks, berths, fixtures, per-seat premiums and reusable templates.
    Outcome
    Operators onboard any fleet themselves, without an engineering request.
  3. 03

    The moment money moves

    Problem
    A phone can lose signal after the money leaves but before the ticket appears.
    Decision
    Server-calculated fares and server-side Razorpay verification; the essentials go out by SMS so they work without data.
    Outcome
    A confirmed booking always corresponds to money actually received.
  4. 04

    Authority in small pieces

    Problem
    Approving operators, refunds and payouts needs real power — but not everyone should hold all of it.
    Decision
    Role-based permissions composed per responsibility, enforced centrally, with an audit log of consequential actions.
    Outcome
    The team can grow without every new hire holding the keys to the business.

What shipped

Everything that was delivered.

  • Passenger app

    iOS & Android (Expo): route search, live seat map, booking, tickets, cancellations and saved refund accounts.

  • Operator portal

    Fleet, bus layouts, routes, trips, bookings, boarding and earnings for bus companies.

  • Admin portal

    Operator approvals, refunds, settlements, commissions, campaigns and role-based staff access.

  • Bus layout designer

    Two-deck, sleeper and seater layouts with per-seat pricing and women-reserved seats.

  • Payments & notifications

    Razorpay with server-side verification; SMS, email and push tickets and alerts.

  • Marketing website

    Public site for travellers and operator sign-ups.

Tech stack

  • React Native
  • Expo
  • React
  • Vite
  • shadcn/ui
  • Node.js
  • Express
  • PostgreSQL
  • Drizzle ORM
  • Redis
  • Razorpay
  • Twilio
  • SendGrid
  • AWS S3
  • OpenAPI

Want results like these for your business?

Tell me what you need in two minutes. You'll hear back within 24 hours, and get a fixed-price proposal within 48 hours of our call.

  • Reply within 24 hours
  • Fixed quote in 48 hours
  • NDA on request