KhaliSeat — Ride-Sharing & Vehicle Listing App
A regional ride-sharing app for Azad Kashmir where drivers publish the empty seats on a route they're already driving, and riders search by pickup, drop-off and date. Built and published to Google Play end to end.
Case study
How this was built, in the order I'd walk someone through it.
- 01
Problem
Intercity travel in Azad Kashmir runs largely on cars that are already making the trip with seats to spare, matched informally through phone calls and word of mouth. The dispatch model that ride-hailing apps are built around doesn't fit — nobody is driving around waiting for a fare. What was missing was a way to publish a journey that's already happening and let riders find it.
- 02
Users
Riders searching a routeVehicle owners publishing spare seatsVerified transport companies - 03
Architecture
A Flutter application for Android, built against a REST backend, with the release pipeline and store presence managed through Google Play Console. Riders and vehicle owners are separate account types over a shared listing model.
- 04
My responsibility
Everything — product, app, release and store listing. I built it end to end and published it myself.
- 05
One important feature
Search shaped like the actual journey
A rider searches by pickup, drop-off, date and gender preference, and the results are a live feed of ride ads matching that route. Gender is a filter rather than an afterthought because for a large part of the intended ridership it is the deciding factor in whether a shared car is an option at all.
- 06
How it works internally
The listing is the unit of the system. A vehicle owner publishes a ride ad against a route and date; riders query the same records through the search form. Accounts split into rider and owner, with a verified company section for registered transport operators — the trust layer that makes a stranger's car acceptable, standing in for the ratings history a new marketplace does not yet have.
- 07
Challenge
A two-sided marketplace has nothing to show on day one. With no drivers there is nothing to search, and with no riders there is no reason to post — and unlike a city ride-hailing launch, the region has no dense pool of professional drivers to seed from.
- 08
How I solved it
I built for the supply side to be usable before demand existed: publishing a ride ad is fast and standalone, and the verified company section lets established transport operators list without needing an individual reputation first. Riders still see a populated feed on their first open, which is the only version of the app that has a chance of retaining them.
- 09
Trade-off
Android only. iOS would have roughly doubled the release surface — a second store, a second review process, a device fleet — for a small share of the target region's handsets. Shipping and publishing on one platform, alone, beat a longer road to two.
- 10
What I learned
Publishing is a real engineering phase, not a button at the end. Store policy, listing assets, signing, release tracks and staged rollout all took genuine work that never appears in a repository. It also taught me that in a marketplace the hardest problem isn't the code — it's the empty state, and that has to be designed for deliberately.
Screens
Ride search + live listings
Pickup, drop-off, date and gender feeding straight into the ride-ads feed below.
Accounts — rider or vehicle owner
Framed for the supply side: manage vehicles, publish ride ads, track payments. Getting owners to post is the harder half of a two-sided marketplace.
