Business platform for a transport company in Europe
One engine that runs a whole transport business.
01 / The challenge
A transport company in Europe that drives travellers to and from airports runs its whole business on one system: online bookings, prices, payments, vehicles and drivers, agencies and subcontractors. In September 2026 I took that system over to rebuild it.
The business kept running the whole time, and its rules kept changing while I worked. Nothing could be lost on the way: not a booking, not a balance, and not a rule the office relied on.
- A live business that cannot stop
- Rules that changed during the rebuild
- Money that must always add up
- Outside services behind every booking
02 / What I built
One Python engine, built to serve three sets of screens: the office console, a customer app and the public site. Every price, every seat count and every refund is worked out on the server, and every outside service is connected through a switch that stays off until it is turned on for real.
Where the business had not decided a rule yet, I built it whole behind a setting that is off, and tested it both ways. The decision is a switch, not new code.
How it came together
- 2026-09Taking overI take over the live system and seal the earlier code as a reference.
- 2026-09Capability audit525 capabilities compared in 12 areas; 380 become the rebuild's backlog.
- 2026-10Tests at two datesThe full suite runs at today's date and again at a date months ahead.
- 2026-10Ready to connectThe engine is built and tested; the office screens come next.
03 / Highlights
Bookings and pricing
One-way and round trips, private rides and shared shuttles. Every price is worked out on the server; a request never brings its own.
Payments and refunds
Card payments, holds for bookings that wait for approval, deposits, a cancellation scale fixed at the time of sale, and refunds never above what was paid.
Dispatch
Picks the right vehicle, fills shared rides, proposes merges and warns the office about any ride that has no driver.
Partners and subcontractors
Agencies book on credit through a portal or a partner API. Subcontractors and drivers get each job through a secure link that expires.
Flights
Booked flights are watched. A delay moves the pickup, and a cancelled flight alerts the office, which can tell the customer in one click.
Messages
Email and instant messages, and each one goes out only if the event behind it was saved.
Back office
Staff roles and permissions, a record of every change to money or bookings, cost and margin reports, backups and a data importer.
04 / How it fits together
Design noteReal screens come later, with the client's agreement. Until then the system is shown in two diagrams drawn in this site's own style: one engine with every part of the business around it, and one booking from start to finish.
05 / Impact
The engine behind the business is built, tested and ready to be connected, and the rules the company has not decided yet are ready behind a switch, waiting for its decision. The office screens and the move to the new system come next.
06 / Role and tech
I am the lead developer and system architect. I designed the architecture, wrote the rules the AI agents had to follow, directed Claude Code and reviewed every change.
The office console is built on my own component library, so its look and feel are my work.
Tech
- Python
- Flask
- SQLAlchemy
- Alembic
- Pydantic
- PostgreSQL
- React 19
- Mantine
- Astro
- pnpm monorepo
- pytest
- Claude Code
How it's built
A pnpm monorepo. One Python engine (Flask, SQLAlchemy, Alembic, Pydantic), layered from routes to services to repositories, with PostgreSQL in production. A React office console on Mantine and my own component library, and a pre-rendered Astro public site. Background work runs in a job runner, and messages leave through an outbox. The engine has nearly 600 API endpoints and more than 19,000 automated tests, run at two dates; 617 of my 625 commits were made with Claude Code.
A whole business in one engine, built so the company can trust it with its money.