KaziWare for Ironhorse Hauliers — transport, fuel and payroll on one ledger
The challenge. A Kenyan haulage operation was running trips, fuel, driver payroll and customer invoicing across separate spreadsheets and WhatsApp threads. Nothing tied a trip's cost to its invoice, a fuel entry could be captured twice with nobody noticing, and month-end meant rebuilding the numbers by hand before anyone could say whether a route had made money.
What we built. KaziWare — a Transport & Logistics Management System in plain PHP and MySQL, running on ordinary cPanel shared hosting so it costs the business almost nothing to run and any competent developer can maintain it. Dispatch, fuel, HR and payroll all post into a single double-entry general ledger, so a trip, the diesel it burned, the driver who ran it and the invoice it produced are the same set of records rather than four.
How the money is protected. These are the controls the system actually enforces, and they are the reason we can talk about it:
- The trial balance must be 0.00. It is a gate in the automated test suite, not something a person checks. A change that unbalances the books cannot be accepted.
- Postings are replay-safe. Every ledger entry carries a unique posting key, so a payment callback that arrives twice — which happens on Kenyan payment rails — posts once and the duplicate is rejected outright.
- Closed periods stay closed. Once a month is closed the system refuses to post into it, so last month's reported figures cannot quietly change.
- Every state change leaves an audit row. Who did it, when, and what it was before.
- Statutory payroll is built in. PAYE, NSSF and SHIF are calculated in the system, not in a side spreadsheet, and the returns come out of the same data that paid the staff.
How it is shipped. Every release is proven before it leaves us. An automated PHP test suite rebuilds the database from the installer and runs against real fixtures. The interface is checked in a real browser at both 1366px and 390px — the phone width people actually use — for accessibility failures, layout overlaps and JavaScript errors, and all three must be zero. Then the release is installed clean on an empty database and the whole suite is run again from the packaged zip, exactly as the client will receive it. Database migrations are written so that running them twice is safe, and the installer and the upgrade path are proven to produce the same schema.
Where it is now. In production, on the client's own hosting, with the source and the installer in their hands. The roadmap is delivered in phases; each phase ships with a written note of what was built, what was deliberately not built, and the proof numbers behind it.
Operational figures. We do not publish numbers we cannot source. Time and cost figures for this engagement will be added here once Ironhorse have confirmed them from their own records.
What we can show you, whatever the project
Most vendors describe their process. These are things you can ask us to demonstrate on the spot, on any engagement:
- The test suite running, and the trial balance landing on zero.
- A duplicate payment callback being refused.
- A release installed from scratch on an empty database, and the tests passing from the shipped package.
- The accessibility and layout checks running at phone width.
- The release note from the last delivery — including the part that says what we did not build.
If a supplier cannot show you those, ask how they know their last release was safe.
References
We are happy to put you in touch with clients directly. We do not publish quotes, logos or figures without written permission, which is why you will find fewer of them here than on most agency websites — and why the ones you do find are real.