I never planned to build software. I planned to fix a few problems in a freight business. The software is what happened when I wrote the problems down and noticed they were all the same problem.
This is the story of why I am building an ERP for freight forwarders, what I learned writing it, and where it stands today. No company or client is named, and I am not claiming results I have not yet measured.
First, what is an ERP?
ERP stands for enterprise resource planning. Forget the name. An ERP is simply one system that a whole business runs on, instead of ten separate spreadsheets, email threads and paper files.
Think of a hospital. If every doctor kept their own notes in their own notebook, a patient moving from the emergency room to surgery to the ward would have to tell their story three times, and something important would be lost. A hospital record system means every department sees the same patient file. An ERP does that for a business: one file per job, which everyone can see and nobody has to retype.
The problems that would not go away
Over the years, across sales, overseas coordination, tenders and business performance, I kept seeing the same leaks. Not in one company only, but in the pattern of how many traditional forwarders work:
| What happens | What it costs |
|---|---|
| A rate is requested from a partner every time a client asks, because there is no bank of saved rates | Slow quotes, and the same route priced twice in one week at two different prices |
| The quote is made in one system, then rebuilt by hand in Excel to work out the job's profit | Hours of retyping, and mistakes that nobody catches |
| A new job is opened with no check on the client's unpaid balance or credit limit | Work done for clients who already owe too much |
| Payment requests travel on paper from desk to desk for signatures | Containers waiting at the port while a form waits on a desk |
| Updates live in WhatsApp chats and phone calls | Nobody can see where a job is without asking somebody |
| A charge is agreed with the client but never put on the invoice | Money earned and never collected |
None of these is a big disaster on its own. Together they explain why a freight business can be busy every day and still short of cash at the end of the month.
The pattern behind all of them
When I put the list together, one thing stood out. Almost none of these problems happens inside a department. They happen between departments.
Sales agrees the price. Operations spends the money. Accounts raises the invoice. Each department does its own part well, but the job passes between them through paper, spreadsheets and memory, and that is where the money leaks. In freight, money is rarely lost inside a department. It is lost in the space between two of them.
Training people harder does not fix a gap between departments. A system that carries the job from one desk to the next does.
Why not just buy one?
Good freight systems exist. I have used some and evaluated others. The large international ones are built for large international companies: they are priced in dollars, they need consultants to set up, and they assume a world where customs, payments and partners behave the way they do in Europe or America.
Nigerian freight has its own realities. Form M (the form an importer must register before goods are shipped), agency permits, customs systems that change, money paid out in naira and dollars on the same job, disbursement charges (the fee for paying costs on a client's behalf), and clients whose purchase orders arrive weeks after the work is done. A system that does not understand those things forces people back into spreadsheets, and the leaks return.
So I started writing down what a system built from inside the trade would need to do.
How it is being built
Specification first, code second
The first rule was: no code until the rules are written. I started from the company's own written procedures, department by department, and worked through every process one question at a time. Who raises this? Who approves it? What document must be attached? What happens if it is rejected? Only when the answers were written down did any building start.
This took longer than writing code. It was also the most valuable part, because it forced decisions that had never been made out loud.
Built with AI, directed by someone who knows the trade
I am not a professional programmer, and I do not pretend to be one. I design the product, write the rules and make the decisions, and I use AI tools to write the code under my direction. That is a new way of building software, and it changes who can build it: the person who understands the problem can now build the solution, instead of explaining it to someone who has never cleared a container.
It also brings a duty. Code written quickly must be checked carefully. So the system went through an independent code review, and the problems found were fixed before it moves to live use.
The design rules
- One file follows the job from first enquiry to final payment. Nobody retypes it.
- Profit is checked before the invoice, not discovered months later.
- Standards come from lists, not typing. Ports, airlines, units, countries and trade terms are picked from global lists, so nobody misspells a port or mixes kilograms and pounds.
- Rules are settings, not code. Who approves what, the spending limits and the tax rates can be changed by the business without a programmer.
- Plain words everywhere. If a new staff member cannot understand a screen, the screen is wrong, not the staff member.
Where it stands today
The first piece to go live was a digital approval system that replaced paper payment requests. I wrote about it in Going digital in freight forwarding. Staff have started using it.
The full ERP covers quotations, operations and customs documents, warehousing, trucking, approvals, HR, payroll and accounts. It is in testing with its first freight forwarder and moves to live servers this month. I will share what happens, including what goes wrong, because a build log that only reports good news is not worth reading.
What I have learned so far
- The software is the easy part. Agreeing the rules is the hard part. Every business has habits that were never written down.
- Write the procedures before you buy or build anything. A system cannot enforce a rule nobody has agreed.
- Fix the gaps between departments first. That is where the money is.
- Change one process at a time. People trust a second change when the first one worked.
If you run a freight business and you recognise the table above, start small: pick the one gap that costs you most and write down exactly how the work moves through it today. That page is the beginning of any system worth having. And if you want to compare notes, write to me or see what I am building.