The problem
Orders arrived by phone and WhatsApp and were written down. Somewhere between the person taking the order and the truck being loaded, details drifted — the wrong quantity, the wrong customer reference, a load number nobody could trace back. The errors surfaced at the loading gate, which is the most expensive place to find them.
The owner could see the pattern but not the cause. There was no single record of what had actually been agreed, so every dispute came down to whose memory was better.
What we built
A custom order management system with two surfaces: a mobile app the staff actually use, and back-office screens for the reference data behind it — customers, products, transporters, regions.
An order is captured once, on a phone, by the person taking it. It draws on records that already exist: the customer is selected rather than retyped, products carry their own packaging maths, and the transporter is chosen per load rather than assumed from the customer. What used to be re-entered every time is now selected — which is where most of the errors were coming from.
Every order gets a unique, sequential number at the moment it is created, and that number is what everyone downstream refers to.
The unglamorous part that makes it trustworthy
Order numbers are generated by the database, not the app. That sounds like a technical detail; it is the difference between a system you can trust and one you can't. If two staff capture an order at the same moment, they cannot receive the same number — we tested that with fifty simultaneous orders, deliberately, before the client ever saw it.
Nothing is ever deleted. A customer or product that is no longer used is deactivated, so the orders that reference it still make sense a year later. Every change is written to an audit log that the database itself prevents anyone from editing or erasing — not by policy, but by design.
Anything printed or read aloud to a customer is frozen once it has been used. A customer's code is baked into loading numbers already issued, so once an order references it, it cannot be changed. The same applies to a product's packaging. These are the rules that stop a system quietly rewriting its own history.
Privacy built in, not bolted on
The system deliberately does not collect driver ID numbers or personal cell numbers. It captures the driver's name and the vehicle registration, because those are what the business needs to identify a load — and nothing further.
That was a design decision made in writing before the first screen was built, not a compliance exercise at the end. Under POPIA the cheapest personal information to protect is the kind you never collected. It is also the easiest promise to keep.
How we worked
Every screen was specified in plain English and signed off before any code was written. Where a decision was genuinely contested — how customer codes should be derived, what happens when an order needs reversing — we wrote it down with the reasoning and the alternatives, so the client could disagree while it was still cheap to change.
Development ran against a separate database from the first day, so no test, no migration and no experiment ever touched the client's live orders. The order number sequence is the one figure they read aloud to customers; it was never at risk.
The client owns everything — the code, the database, the decisions.
What this means for your business
If your business loses money between the order being agreed and the goods going out the door, the fix usually isn't a bigger spreadsheet. It's one record of what was agreed, created once, that nobody can quietly change.
We build systems like this from a written spec you approve before we start, with milestone payments matched to your cashflow. Book a discovery call and we'll scope it honestly — including telling you if you don't need custom software at all.