From spreadsheets and messaging apps to one operational platform.

The challenge

The operation had outgrown the tools holding it together.

Passenger transportation looks straightforward from the outside: publish a schedule, sell a seat, assign a bus, and complete the trip. Behind the scenes, the operation is a dense network of dependencies.

Passengers need to be connected to the correct departure and seat. Vehicles and drivers need to be available at the right time. Routes can span multiple stops and countries. Trips generate mileage, fuel records, cash, expenses, ticket records, manifests, and travel documents. Last-minute changes have to be reflected across the operation without losing track of what changed.

For this company, much of that work was being coordinated through Excel, Viber, WhatsApp, a calculator, and manual communication. Information lived in different places, calculations had to be repeated, and important operational knowledge often depended on the person handling the task.

At a fleet of roughly 50 buses and a network of around 30 drivers, that approach placed a significant amount of operational work on the company owner and office team. Running the business meant constantly checking, calculating, reconciling, calling, messaging, and making sure information in one place still matched information somewhere else.

The problem was not a lack of software. It was that the operation had no single system built around the way the business actually worked.

The goal

Build around the operation instead of forcing the operation into another tool.

The goal was not to digitize one isolated task.

It was to understand how the company actually operated from the moment a passenger searched for a trip through to the moment a completed journey was reconciled — then build a system around those workflows.

That meant treating booking, dispatch, drivers, vehicles, seats, money, fuel, ticket stock, packages, and reporting as parts of the same operation rather than separate software problems.

The system also had to account for the details that generic software often ignores: return journeys, transfer departures, seat allotments, multiple vehicles on the same departure, resource conflicts, international mileage, driver settlement, physical ticket serials, and changes that happen while the operation is already moving.

One system. Different roles. One source of operational truth.

The solution

A custom operational platform connecting the business from booking to reconciliation.

Cerato Systems built an end-to-end application with interfaces for passengers, office operations, management, and drivers.

Instead of replacing one spreadsheet with another isolated tool, the platform connects the major workflows of the transportation business through shared operational data.

A reservation created through the public booking experience becomes part of the same operational system used to assign seats, plan departures, allocate vehicles and drivers, manage trips, reconcile money, and generate reports.

The result is a system designed around the lifecycle of the work rather than around the boundaries of individual departments or generic software products.

• Passenger booking
• Reservations & seats
• Routes & departures
• Daily dispatch
• Fleet & drivers
• Driver trip workflow
• Mileage & fuel
• Financial reconciliation
• Ticket inventory
• Packages
• Operational reporting

Passenger booking

Booking is connected directly to the operation behind it.

Passengers can search available trips, select a journey, reserve seats, book return travel, and receive confirmation through the public-facing application.

Behind that interface, the booking is not treated as a disconnected ecommerce transaction. It becomes an operational record tied to the departure, route, passenger, seat capacity, and the rest of the transportation workflow.

The system supports route-stop sequencing, segment-level fares, one-way and return journeys, different passenger fare types, transfers, linked departures, and seat availability rules.

That connection between the customer-facing experience and the internal operation removes the need to recreate booking information manually in a separate back-office process.

Passenger booking feeds directly into the same system used by the operations team.

Daily operations

The software reflects how transportation work actually happens.

The operational side of the system brings routes, departures, reservations, passengers, vehicles, and drivers into one working environment.

For each day, the team can see what is running, assign vehicles and drivers, manage additional buses when demand requires them, and move passengers when operational changes make that necessary.

The system checks for overlapping vehicle and driver assignments rather than relying on someone to remember every conflict manually.

Seat assignment is also connected to the underlying departure, vehicle layout, capacity, and allotment rules. The objective is not simply to store data — it is to prevent operational mistakes before they become problems on the road.

• Daily vehicle and driver allocation
• Resource-overlap checks
• Multiple buses on a departure
• Passenger reassignment
• Seat layouts and availability
• Seat allotments
• Regular and special departures
• Transfer / linked departures
• One-way and return passenger lifecycle

Daily dispatch connects departures, passenger demand, vehicles, and drivers in one operational workflow.

Driver operations

The trip continues inside the system after the bus leaves the station.

Drivers have a dedicated workflow for the journeys assigned to them.

During and after a run, the system can capture the information needed to close the trip operationally: mileage, fuel, passenger counts, cash, expenses, and travel-order information.

This matters because the physical journey is only one part of completing a transportation service. The business also needs a reliable record of what happened during that journey and what needs to be reconciled afterward.

The driver interface keeps that process connected to the same departure and operational data already used by the office team.

Built for work that happens on the road.

Driver workflows cannot assume a perfect office connection. The driver application includes offline-oriented behavior that can preserve selected reads and queue writes locally when connectivity is unavailable, allowing important trip work to remain practical in real operating conditions. Once connectivity is available again, queued work can continue back into the central system.

Financial control

Operational data and money are reconciled in the same workflow.

One of the most important parts of the project was improving control around the money and records associated with each trip.

When cash, passenger counts, fuel, expenses, and ticket records are managed through separate conversations and calculations, discrepancies can be difficult to detect and even harder to trace back to the trip that created them.

The platform ties financial and operational information back to the journey itself. Driver settlement, passenger counts, collected cash, fuel entries, expenses, and related records can be reviewed as part of a structured trip-closing process.

This gives management a much clearer basis for checking what was expected against what was recorded, and reduces the opportunity for mistakes, omissions, or unexplained discrepancies to pass unnoticed.

The system does not just record what happened. It gives the business a way to verify it.

Beyond the core trip

The smaller operational details were part of the system too.

A real transportation business contains important workflows that rarely appear in generic booking software.

The platform includes supporting tools for the operational details that still need to be controlled every day.

A departure remains manageable after the booking is made.

The operations team can work directly with the passengers attached to a departure, review boarding and payment states, inspect passenger records, and take the actions required as the journey approaches. That keeps the operational passenger list connected to the same departure data that originated earlier in the booking process.

Passenger records remain connected to the departure, including boarding, payment status, and operational actions.

Built for complexity

Simple screens sit on top of complicated business rules.

Much of the engineering work in this project is invisible in a screenshot.

Transportation operations contain dependencies that have to be modeled correctly for the interface to remain simple: which route segment a passenger is travelling, which seats are actually available, whether a vehicle or driver is already committed elsewhere, how a return journey relates to the outbound booking, and how one departure changes when more than one bus is required.

The platform turns those rules into validations and workflows so the people running the operation do not have to reconstruct the logic manually each time.

• Segment-aware routes and fares
• Seat capacity and allotment rules
• Multi-bus dispatch
• Vehicle / driver conflict checks
• Round-trip passenger lifecycle
• Transfer and linked departures
• International mileage separation
• Trip-level financial reconciliation
• Physical ticket serial controls
• Driver offline-oriented workflows
• Operational document generation

The complexity stays in the system so the workflow can stay understandable for the person using it.

Engineering

Designed and built end to end.

The project was built as a complete software system rather than a collection of disconnected interfaces.

Cerato Systems was responsible for the application architecture, frontend, backend business logic, data model, integrations, operational workflows, exports, and ongoing development.

The public-facing application is built with Next.js, React, and TypeScript. The operational backend is implemented as a custom Odoo module in Python with PostgreSQL as the database.

The system connects the public booking experience to the operational back office through server-side integration, while email services support passenger confirmation workflows.

The technology was selected and shaped around the needs of the operation. The important outcome is not the framework list — it is that the customer-facing experience, internal workflows, business rules, and data all operate as one system.

Technology

• Next.js
• React
• TypeScript
• Python
• Odoo
• PostgreSQL
• JSON-RPC integrations
• Email delivery
• XLSX / image exports
• PWA / offline-oriented driver workflow

Scope of ownership

• Product / workflow design
• Frontend engineering
• Backend engineering
• Data modeling
• Business-rule implementation
• Integrations
• Operational exports
• Responsive interfaces
• Production implementation
• Ongoing maintenance & development

What this project represents

Custom software is most valuable when the business has outgrown generic tools.

This project is not valuable because transportation companies need another booking application.

It is valuable because the business had developed its own operational rules, exceptions, responsibilities, and ways of working — and the tools around it were no longer enough to manage that complexity cleanly.

Cerato Systems turned those workflows into software built around the operation.

That is the kind of problem we are built to solve.