Selected work / 01

Travel Eco System

I built a single booking engine to run an entire 500+ vehicle fleet — connecting passenger phones directly to driver dashboards in real time.

An end-to-end mobility platform for Padma Sri Travels — public booking website, admin dispatch console, and dedicated driver and passenger apps, all sharing one unified backend.

Role — Product Design, Frontend & Backend Development Timeline — 2025 Stack — Next.js · Supabase · GSAP · Claude Code
Travel Eco System — 4 Surfaces Staged

Services provided

Product Design Frontend Dev Backend Dev

Deliverables

Booking Website Admin Panel Customer App Driver App

Stack

Next.js Supabase GSAP Claude Code + GitHub

Client

Padma Sri Travels

Hyderabad fleet operator · B2B corporate contracts & B2C rentals

01 — The problem

A 500-vehicle fleet managed entirely on phone calls

When I sat down with Padma Sri Travels, I saw a serious fleet business — corporate contracts with companies like GMR Hyderabad Airport and BHEL, 500+ chauffeurs, and an expanding EV fleet. But beneath the surface, everything was held together by phone calls, messy spreadsheets, and WhatsApp groups that couldn't communicate with their static website.

Dispatchers were assigning rides from memory. Drivers had no digital schedule. Customers had to call in just to find out where their car was. There was no single source of truth connecting what a customer booked, what dispatch sent out, and what a driver actually drove that day.

Stat — to confirm

[     ]

Manual phone bookings coordinated every week

Stat — to confirm

[     ]

Disconnected spreadsheets used before this rebuild

02 — The approach

Four surfaces, one single database

Instead of building four separate apps with conflicting opinions, I connected everything to one single Supabase database. I unified the shared business logic — our pricing engine and booking policies — across codebases so a fare quoted on the website is the exact same number the operator dispatches and the driver sees on the road.

Surface 01

Booking Website

The public storefront — turns visitors into confirmed bookings with instant pricing.

Surface 02

Admin Panel

The dispatch hub — fleet availability, driver allocation, and B2B accounts in real time.

Surface 03

Driver App

The roadside tool — simple trip manifests, navigation, and one-tap status updates.

Surface 04

Customer App

The passenger app — fast on-the-go bookings, saved corporate profiles, and live trip tracking.

Travel Eco System Architecture — 4 Surfaces, 1 Backend

03 — Module deep-dives

Four products, four problems to solve

Module A

Booking Website

The challenge — Visitors couldn't easily get from browsing to booking without a phone call. Fleet options and pricing were completely opaque, leading to high drop-offs.

PST-WEB-01 // EXPLORE FLEET & SEARCH CATALOG
PST-WEB-01 // EXPLORE FLEET & SEARCH CATALOG
PST-WEB-02 // CORE RESERVATION & TRANSIT MODE
PST-WEB-02 // CORE RESERVATION & TRANSIT MODE
PST-WEB-03 // ROUTE COORDINATES & MAPS TELEMETRY
PST-WEB-03 // ROUTE COORDINATES & MAPS TELEMETRY
PST-WEB-04 // PACKAGE SELECTION & DYNAMIC PRICING
PST-WEB-04 // PACKAGE SELECTION & DYNAMIC PRICING
PST-WEB-05 // RESERVATION CONFIRMATION & ORDER TICKET
PST-WEB-05 // RESERVATION CONFIRMATION & ORDER TICKET
PST-WEB-06 // USER PORTAL & BOOKING HISTORY
PST-WEB-06 // USER PORTAL & BOOKING HISTORY

Key decision

I integrated the Google Routes API to calculate real road distance on the fly. Customers get an honest, real-time fare upfront — no hidden fees, and no "call for a quote" friction.

Outcome

Collapsed searching, quoting, and payment into one friction-free flow

04 — Under the hood

The engineering behind the design

RLS security gap

I discovered and locked down an open Row-Level Security policy that exposed customer phone numbers, then re-audited all query boundaries.

One pricing engine

I built a single shared pricing.ts engine so every app calculates and quotes the exact same fare, every single time.

Custom driver auth

I implemented token-based authentication using bcrypt, Supabase Edge Functions, and a dedicated sessions table tailored for shared driver phones.

Routes API migration

I transitioned our distance math from Google's deprecated Directions API to the Routes API, wrapping calls in a secure server endpoint to protect API keys.

Redux Toolkit rebuild

I re-architected the admin console state using Redux Toolkit, keeping live vehicle tracking and dispatch queues buttery smooth as the fleet expanded.

I owned the full product lifecycle — product design, frontend interfaces, backend services, and data security.

05 — Results

What the clients say

"We moved 1,200 employees to Padma Sri for the daily commute and on-time compliance jumped to 98%."

Vamshidhar — GMR Hyderabad International Airport

"Their night-shift transport for our 600-member team has run flawlessly for three years."

Sumanth — Tata Elxsi

Stat — to confirm

[    ]

Total online trips booked through the new platform

Stat — to confirm

[    ]

Dispatcher time saved per ride assignment

Verified

ISO 9001:2015

Client certification, publicly listed

Verified

Startup India

Recognised operator

06 — Reflection

Hardest trade-off

Building four surfaces on a tight schedule meant keeping the driver app strictly focused on essentials — trip manifests, live status, and trip history — and holding off on extras until dispatch was rock-solid.

With more time

I would have run deep database security audits earlier. Fixing that open RLS policy was straightforward, but catching it after three apps were already in progress was an important wake-up call.

Shipping next

Next up: an automated AI customer support agent, expanding the fleet past 100 electric vehicles, and launching the passenger app on the Google Play Store.