Replacing paper tickets and mental arithmetic for a small South African timber operation.
Two owner-operators split field work and admin between them, sourcing untreated eucalyptus poles, droppers and laths from their own and third-party land. Until now, all of it ran on paper tickets, a physical shop ledger and manual arithmetic. This is a Windows desktop app and an Android app that share one set of data — parties, pricing, stock, tickets — kept in sync by a small host server.
Placeholder data — business and personal names genericized for this case study.
How it works
Desktop leads with a business-wide overview — today's timber in, today's invoicing, outstanding customer balance, low shop stock and yard stock on hand — plus a launcher into every module and a running "needs attention" list.
Every tile links to the correct, platform-formatted version of its module. Nothing here is decorative-only — a standing rule that applies to every screen in the system.
Android leads with today's field activity and one-tap entry into each module — used at the depot and on-site, in one hand's reach. It is a genuinely different app from the desktop one, not the same screen squeezed narrower.
Remote Assistance jobs — an owner taking an operator and a chainsaw out to a supplier's site — are captured differently per platform on purpose: inside the ticket on Android, as its own tab on desktop, where the admin view of every open job's balance belongs.
Droppers and laths are logged in bundles of 10, from which pieces, linear metres and m³ are all derived automatically from the business's own per-length factor tables — no more hand-calculating a delivery.
A ticket is saved as a draft after intake, then completed later after sorting with an accepted count and a reject figure — mirroring the real two-moment paper workflow instead of forcing one pass through a form.
An on-site shop for staff essentials, paid through payroll deduction rather than cash. Orders reserve stock immediately — blocking oversell outright, not just warning about it — and a consolidated pick list sums everything pending into one shelf-picking run.
Only delivery decrements on-hand stock and credits the employee's running wage balance. Cancelling an order releases its reservation cleanly, exactly as shown here.
Standing design rules
Money
Cubic-metre volume is calculated everywhere internally but deliberately never shown on anything customer- or supplier-facing — it carries a muted "Internal" badge wherever it appears in the UI instead.
Suppliers, landowners, transporters and contractors are all paid on bundle counts or linear metres, never m³. One number for running the business, a different one for paying people — and the software keeps them from ever mixing.
Two platforms
Desktop screens use a fixed-width landscape shell — sidebar nav, multi-column grids, a real minimum width — that never collapses into a mobile-style single column. Android is the opposite: portrait, single-column, everything within a thumb's reach.
Neither platform is a resized version of the other. They're built for two different moments in the same working day.
Data model
Customers, suppliers, landowners, transporters and contractors all live in a single parties database — a party can hold more than one role at once. Pricing lives on the party's own record, because this business prices per relationship rather than off a single depot price list.
The same principle is planned for staff once the employee register unblocks: one register, every module reads from it.
History
Removing a product or an employee who has order history behind them archives the record rather than deleting it — it disappears from active pickers but stays visible, with a Restore option, so past transactions and outstanding balances stay intact.
Where the value actually is
The system's value is less about adding new capability and more about replacing manual, error-prone paper and mental-math steps with rules that get applied the same way every time.
Get in touch
This is the kind of system I build: module by module, with the business's own rules enforced by the software instead of remembered by a person.