What I get called in for
Three problems, described the way a business owner would describe them rather than the way a developer would. If yours is close but not quite, say so — the shape usually transfers.
Consolidation and reconciliation
Your numbers live in five different places
Several payment providers, more than one entity, sometimes more than one currency. Each provider reports fees differently, and the ledger sees a net figure days later. Nobody can say what came in this month or what it actually cost.
I pull every provider into one normalised view, convert to a single reporting currency, and reconcile against your accounting system — surfacing what will not match instead of pretending it did. Your ledger stays the system of record; nothing writes back to it.
Order-to-dispatch platforms
A platform takes a cut of every order
Marketplace commission compounds quietly, and it buys you a customer relationship you do not own. Running your own drivers is cheaper and usually worse to operate, because nobody can see where anything is.
I build the layer in between: orders in by webhook, routed to the right location, dispatched with a real route, visible to everyone who needs it — dispatcher, driver, supplier and the customer waiting at the other end.
Case and document automation
The same admin happens every week, by hand
Chasing the same documents, re-keying the same orders, sending the same status update. Work that is identical every time is work a system should be doing.
The judgement call is what to automate and what to leave alone. Structured, repetitive exchanges get templates — instant, free, identical every time. Anything where tone carries real weight stays with a person, or gets drafted with enough context that it reads as informed rather than generically kind.
How it usually goes
- A conversation. What happens now, who does it, and how long it takes. Often enough this ends with me saying you do not need me.
- A written scope. What gets built, in what order, and what it costs. The riskiest part goes first, so the uncertainty is retired early rather than at the end.
- The build, in modules. Each one independently useful, so there is something working before everything is finished.