I've run a manufacturing company and built the systems that ran it. Production, inventory, maintenance, HR and accounting — designed by someone who managed those departments before writing a line of code for them.
End-to-end web applications — backend, interface, database, deployment.
Custom systems for manufacturing — from the shop floor through to the accounts.
Line balance, flow, capacity and cost modelled before the change is built.
Analyse, redesign and optimise operations before they get digitised.
Not a developer who consulted a factory. Someone who owned one, carried its payroll, and signed off its accounts — then wrote the system that replaced the spreadsheets.
Running a manufacturing company means every department eventually lands on your desk. Production, purchasing, HR and accounting all reported to me — hiring and payroll on one side, cost, cash and the books on the other.
That's why the systems I build don't stop at the shop floor. Most manufacturing ERPs are written by people who understand production and treat HR and accounting as afterthoughts. I ran those departments, so I know what they need to close a month.
It also changes how I scope. When a client describes a problem in production, I already know which parts of it are really a costing problem, a staffing problem, or a process that should be fixed before it's automated.
Each described the way an engineer would describe a part: what it does, for whom, and what it replaced.
A full ERP for a tooling and extrusion plant, written from scratch. It started as a job-order tracker and became the system the workshop runs on — because the person writing it was also the person the missing feature was hurting.
Preventive tasks run per machine on fixed cycles — daily through yearly — each carrying a last-done date, because no plant starts with new machines. Printable orders go out to the crew, come back signed, and close against the scan. Self-hosted on plant hardware.
The broadest of the three: a company-wide system covering operations end to end, from user administration and part coding through to the accounts.
A single coding scheme runs through every module, so a part means the same thing to the workshop, the store and the accountant.
A focused system for a production studio working project by project, where the two questions that matter are whether the job is still inside its budget and who is contracted to deliver it.
Spend stays visible against each project while it is running, not after it closes. The crew database holds contracts and details in one place, each person carrying the history of the projects they've worked on. The studio's own site was delivered alongside it.
Reference articles plus working calculators for mold, die and extrusion work.
Brand and site for a construction and engineering supplies company.
Site for the production studio whose ERP is listed above.
Further sites, internal platforms and in-house systems aren't listed here — some belong to clients, some to companies I've worked in. Happy to walk through them on a call.
Most ERP projects don't fail on code. They fail because nobody could translate between the shop floor and the developer.
I spent two decades in mold and die engineering — designing dies, managing production, and running the company those departments belonged to. Then I learned to build the software instead of working around it.
I trained as an industrial engineer and took a Lean Six Sigma master's, which changes what I do first. A bad process automated is still a bad process — only faster, and now expensive to change. The waste comes out before the code goes in, and where the decision is big enough, the change gets simulated before anyone commits to it.
I work in English with international teams and suppliers every day, and I write publicly about engineering and manufacturing systems.
The stack is the easy part. What takes twenty years is knowing what to build with it.
Send the messy version — the spreadsheet, the paper form, the process nobody has written down. That's usually where the real spec is.