What we tested before launching a taxi service: money logic, commission splits and role boundaries

We built VOLT, a taxi service for a small city in Ukraine, from scratch: a dispatcher panel (15 screens), one mobile app for both passengers and drivers (23 screens), a service site, fares, city zones and a financial loop with driver balances and promo codes. Everything runs on one backend.

Stack: Laravel 13, React Native / Expo, MySQL, maps.

This post is not about screens. It is about the checks that decided whether day one would go well.

1. An overnight run of all the money logic

Before launch we did a separate overnight run of everything that touches money. It found the bug that would have broken day one: production still had the old fares. The first passenger would have paid 80 ₴ instead of the agreed 130 ₴, and the driver would have been short by half.

Lesson: test money logic against the data that is actually on production, not only against fixtures.

2. One source of truth for prices

The prices on the home page were once hard-coded by hand. A person saw one number on the site and another in the app. Now the page takes the fare from the same table the ride calculation uses. If a number is shown in two places, it has to come from one place.

3. Commission splits that add up to the kopeck

The commission split was checked in ten variants, including kopecks at 33.33%, and it adds up to the kopeck. Two services in one city share a common order flow: the money goes to the service whose driver took the order.

Rounding is where marketplaces usually leak money. Write the split tests before the first real ride, not after the first complaint.

4. Role boundaries are tested, not assumed

The service owner cannot rewrite the platform terms, draw themselves a balance or see other people's data. These boundaries were tested separately. "The UI does not show this button" is not a permission model.

5. A city directory that builds itself

When a driver taps "I'm here", the service remembers the entrance coordinates. A few hundred rides later the service knows the city's buildings better than any map does. The panel also shows a heat map of when people order over the past weeks, so the owner can see when to put more cars on the road.

What the owner changes without a programmer

Fares and zones are edited by the owner in the panel. The dispatcher sees orders in progress with statuses and pickup timing, drivers with balances, rating, documents and shifts, and finances with daily demand in charts. Passenger data is hidden in the screenshots we publish.

Full case with screens: VOLT taxi service case study

I'm Dmytro Sadchenko, founder of DStudio. We build websites and apps where clients book and pay, plus one system for the owner.