01
Choose the direction
A to B or B to A on a fixed route, with a preferred pickup point saved to the profile.
Direction→
Case study · RutaGo
Fixed routes,reserved seats.
A fixed-route shared transport platform for Peru. Passengers pick a direction, choose an exact seat on a sedan, SUV or van, pay before boarding, and get on against a QR the driver scans into an electronic manifest.
What we designed and prototyped
Seat-level bookingQR boardingLive trackingDriver manifestFleet dashboardPayout approvals
01 — The product
Ride-hailing certainty on a bus-shaped service
RutaGo keeps the economics of a shared van - one fixed route, one fixed fare, many passengers - and adds what ride-hailing taught people to expect: a named driver, a reserved place, a price agreed before boarding, and a vehicle on a map.
The seat is a real object
Sedan, SUV and van each get their own interactive seat map - 4, 7 and 14 places - and occupied seats are locked out rather than merely counted down.
Paid before boarding, not on board
Cards, Yape and Mercado Pago are selected in the app, so the driver never handles a fare and the manifest is settled before the doors close.
One seat, one QR ticket
Every reserved place issues its own QR, companions included, and the driver scans each one into an electronic manifest at boarding.
02 — The problem
Why is a shared fixed-route van harder to build than ride-hailing?
A private ride is one passenger, one price, one decision. A shared van is many strangers competing for the same fourteen places, on a fare nobody is allowed to change, in a vehicle that must not leave half-empty.
Three rules follow from that, and all three are enforced in the interface rather than written in a policy nobody reads: two people cannot take the same seat, a van that leaves half-full loses money, and the fare is not the driver's to set.
37
screens across three surfaces — passenger, driver and operations — designed as one connected system.
03 — Goals & challenges
What RutaGo had to get right
The rules that make a shared, fixed-fare van work are only real if the interface enforces them — not a policy nobody reads.
Goals
Rules, wired into the interface
- Lock a seat, not just count it down — occupied places are unavailable in real time.
- Hold departure until the van is accounted for — full, or the empty seats are paid for.
- Fix the fare centrally — validated by operations, not set by the driver.
- Settle payouts on approval — gross, commission and net payable, signed off by a human.
Challenges
Why it was hard
- Availability is a specific chair, not a number — the seat map has to lock places as they're taken.
- The departure gate lives in the driver app and has to hold until every seat clears, then run a countdown.
- Local payment rails matter as much as cards — a card-only checkout would exclude most riders.
- Three surfaces — passenger, driver, ops — have to read the same route, seat and fare language consistently.
04 — Built for
Who is RutaGo built for?
Three surfaces, one system — passenger, driver and ops — reading the same route, seat and fare language.
Passenger · mobile app
The passenger
Picks a direction, chooses an exact seat, pays before boarding and tracks the van live with Wait-for-Me and driver chat.
Driver · mobile app
The driver
Watches seats confirm in real time, scans each QR at boarding, and works the departure gate and payout requests from the same app.
Operations · console
Operations
Watches the live fleet map, validates fares and commission, and approves the payouts that settle to drivers.
05 — The booking path
How does a passenger go from a route to a seat on a moving van?
02
Pick a driver
Vans running that route list rating, vehicle type, seats left and minutes to departure.
Drivers→
03
Choose exact seats
Sedan 4, SUV 7 or van 14. Occupied places are locked; each selection prices at the fixed fare.
Seat map→
04
Add companions
Travelling companions are named at booking so each one gets a place and a ticket of their own.
Companions→
05
Pay before boarding
Card, Yape or Mercado Pago. The trip is prepaid, so nothing is settled with the driver.
Payment→
06
Tickets are issued
One QR per reserved seat, companions included, held in the passenger app.
QR tickets→
07
Scanned at the door
The driver scans each QR and the boarding lands on the electronic manifest.
Boarding→
08
The van fills, then goes
Departure stays blocked until every seat is taken or the empty ones are paid for; then a three-minute countdown runs.
Departure→
09
Tracked, then rated
Live tracking and driver chat during the trip, a rating and a digital receipt after it.
Trip✓
keep scrolling — the deal glides left →
06 — Inside the product
What does it actually look like?
Thirty-seven screens across three surfaces, designed as one system: the same route, seat and fare language reads consistently whether you are the passenger choosing a chair, the driver holding the door, or the operator approving the payout.
Local rails, not just cards
Passenger · PaymentCard, Yape and Mercado Pago sit side by side with a booking summary and a service fee, because on this route a card-only flow would exclude most riders.
The ticket is the boarding pass
Passenger · TicketsReserved seats issue individual QR codes, with the refund rule stated at the exact step where it stops applying.
The rule that holds the van
Driver · Seat monitorThe driver watches seats confirm in real time; the departure rule and the auto-departure countdown live on this screen, not in a policy document.
Verify, then let them on
Driver · ScanThe QR scanner checks a ticket against the manifest and confirms the passenger, seat and stop in one glance.
Who is on board, in writing
Driver · ManifestThe electronic manifest lists every passenger, seat and boarding state, and exports to PDF for inspection.
Money leaves after a human says so
Ops · PayoutsDriver settlements arrive as approvals with gross, commission and net payable spelled out, and a payment history behind them.
07 — Driver chat
What does the passenger ask the driver?
Live tracking runs alongside an in-trip chat, so a question about the pickup doesn't need a phone call.
PassengerHi, I'm at the pickup point but don't see the van yet.
DriverTwo minutes out, held up at the last stop.
PassengerNo problem, I'll wait right here.
DriverGot it — I can see you on the map. Pulling up now.
08 — Transferable
What does a seat-level booking platform need to get right?
Six things separate a booking platform whose rules actually hold from one that just displays them. They came out of designing and prototyping RutaGo and hold for any capacity-constrained, fixed-fare booking system.
01
A seat is a locked object, not a count
Availability has to be a specific chair held under concurrency, not a number inferred from a stale screen.
02
A departure gate enforced in software
If the rule against leaving half-empty lives in a policy document instead of the driver app, it doesn't hold.
03
The fare is fixed centrally, not agreed on the spot
Prices validated by operations, not set by whoever is driving, are what make a shared fare fair.
04
Local payment rails, not just cards
On a route where card ownership is not universal, wallets alongside cards are what make checkout actually work.
05
One ticket per seat, scanned into a manifest
Proof of boarding has to be individual and auditable, not a driver's memory.
06
Routes as configuration, not code
Directions, vehicle classes, seat layouts, fares and commission all change per city; the seat-locking and payout logic underneath should not.
FAQ
Building a seat-booking transport platform
How long does it take to build a shared transport booking app?
A scope at roughly this size - a passenger app, a driver app and an operations console, with seat-level booking and payments - is a several-month programme rather than a few weeks. What moves the date is not screen count but the seat-locking and payment work: holding a specific seat correctly under concurrency, and settling money to drivers, are where the real engineering sits. We usually ship the passenger and driver apps first and bring the operations console alongside.
How do you stop two passengers booking the same seat?
With transactional seat locking. The seat is held the moment a passenger opens the payment step and released on a timer if payment does not complete, so availability is never inferred from a stale screen. The interface carries its half of the job too: occupied, selected and available are three visually distinct states on the seat map, so a rider is never guessing which chair is theirs.
Can it handle local payment methods rather than just cards?
Yes, and on most routes it has to. RutaGo's payment step puts wallets alongside cards because a card-only flow would exclude a large share of riders. Adding another rail is an integration and a reconciliation task rather than a redesign, because the checkout was built to take more than one from the start.
Why block departure until the vehicle is full?
Because the fare is fixed and shared. A half-empty departure loses the operator money on a route where the price cannot flex, so the rule is enforced in software: the driver cannot start the trip until every seat is sold, or a passenger pays for the seats still empty and the vehicle leaves early.
Can the same platform run other route networks?
Yes. Routes, directions, vehicle classes, seat layouts, fares and commission are all configuration rather than code, so a new city is a data exercise. The parts that stay fixed are the ones worth building carefully once: seat locking, QR boarding, the manifest, and the payout approval chain.
Let's build
Running vehicles on fixed routes?
Tell us how your business actually works and we'll tell you honestly what it takes to build — the seat map, the departure gate, the payouts. No deck, no pitch.