Turning a folder of spreadsheets into one system a freight firm can run.
A Hamburg road-freight operator ran years of its business across dozens of disconnected Excel tabs. I gave tours, trucks, drivers and invoices a single structure, and an interface built for the people who live in it.
The problem
The client arrived with a folder, not a brief: years of a real trucking business, captured across dozens of disconnected Excel sheets. Tours, trucks, drivers, customers, fuel and invoices were all there, just scattered and duplicated. The information existed; the structure didn't.
One tour was logged twice, the driver's name spelled a different way each time.
A tour on one tab had no link to the invoice it produced on another, so the lookup just broke.
The logic that tied it all together, even words like Standgeld, had never been written down.
The approach
Map the system before drawing a single screen.
A flow, not a UI
Working with the developers, I mapped the whole operation: a tour planned, executed, invoiced, booked. As much data modeling as UX.
The model set the menu
Once the entities and their relationships were right, the navigation fell out of them. The architecture followed the data.
Design with engineering
Model and interface shaped together, so every screen maps to a real, relational entity. No orphaned mock-ups.
The requirements map
Nine months of requirements, mapped screen by screen with the client and the developers. Too much to read at once, so pick it up.
The notes are in Turkish, the interface in German.
The questions the spreadsheets couldn't answer
The logic that tied the business together had never been written down; it lived in people's heads. So I asked. Each answer collapsed straight into a screen.
“The current system has no field for the truck's licence plate. Is it needed?”
Yes. A field that didn't exist in nine years of spreadsheets became one.
“Should the invoice date be typed, or assigned automatically?”
Typed. The operator knows something the system doesn't.
“Were these Excel tables often exported and sent on as PDFs?”
Constantly. So a Download PDF button earned its place on every screen.
“What is an Avis?”
I didn't know the word. Asking it turned into a screen.
The architecture
Dozens of disconnected sheets resolved into one relational model: a multi-tenant firm, its legal entity, and everything beneath it: three operational domains, a built-in CRM, an AI layer and a dashboard, spanning more than twenty screens. The app's navigation followed the same logic. Once the model was right, the interface almost designed itself.
Plan a whole week at a glance.
Tours are rows, days are columns. Drag across a few cells and one panel plans the day: label, truck, drivers, note. The board warns you when you've assigned a driver who's marked absent; weekend and today columns are quietly distinguished, and non-billable days are flagged before they cost money at month-end. Below, watch it plan a tour on loop.
The state of a thing is the information.
Is this tour billable? Is this document expiring? Is this invoice overdue? I built one semantic status language and used it identically across tours, vehicle documents and invoices. Learn it once, read it everywhere.
// the same four states, on tours, documents and invoices
Every screen is a real, relational entity.
Drivers, trucks, documents, debts, expenses; each lives in one place and connects to the rest. Sortable, dense tables with per-record detail: leave, documents with expiry dates, and monthly expense sheets. The sidebar you see here is the information architecture, made navigable.
German freight runs on strict rules, and the UI has to keep them.
Gap-free invoice numbering, immutable issued invoices, 10-year retention, DATEV export. These aren't features to decorate; they're promises. So issuing an invoice is a deliberate, clearly irreversible action, and the interface makes the point of no return unmistakable.
The machine drafts. A person decides.
The system reads data from photographed documents, but AI never silently writes financial data. Every extraction is a proposal: the machine drafts, a human reviews per field and approves. The trust model is visible in the interface, not hidden behind it.
If I designed it today
Back when I built this, document AI wasn't reliable enough to trust, so a person had to check every extracted field by hand. Today I'd flip that. The machine fills the record and the person only confirms the few fields it's unsure about, so scanning becomes a matter of trust rather than typing.
Planning would change even more. A dispatcher shouldn't have to read the whole grid to move a single tour. Typing “give tour 817 to Lukas, Monday to Wednesday” would draft the board and flag any conflicts, so the grid becomes the confirmation instead of the input.
And rather than waiting to be opened, the system would speak first: expiring licences, unbilled tours and overdue invoices arriving as a short daily brief.