Our client runs several device repair and retail brands across New Zealand and Australia. Behind the shop counters sits one shared system: repair jobs, parts, stock, dealers, warranties and a public page where customers can track their repair.
Systems like this grow over many years. The challenge isn't building something new — it's improving it safely while live repair jobs are moving through it every day.
The problem with growing systems
Each brand had slightly different rules, and over time those rules ended up spread across the code. Adding a new device type, such as e-scooters, meant editing name lists and dropdown menus in several places. Miss one, and a report or a customer form would quietly show the wrong thing.
One source of truth
We moved the device list and repair warranties into a single shared directory that every brand and the repair dashboard read from.
- Adding a device is now a data change, not a code change in five places.
- Warranty periods live with each device — e-scooters, for example, carry a 90-day repair warranty — and each brand's customer forms apply their own rules on top.
- Reports and filters match exactly, so a device type can't be counted in one report and missed in another.
Changes that can't break history
Years of repair jobs refer to device IDs, so changing them is dangerous. Our database updates are written to be safe to run more than once, and to stop rather than guess:
- If the ID a new device needs is already taken by something else, the update refuses to run instead of renumbering existing jobs.
- If a warranty has already been set by hand, re-running the update keeps it.
- Every change comes with clear deployment steps: check first, apply in order, then release the code.
Opening a new branch
Setting up a new store used to mean hand-writing database inserts. We built a small guided tool that asks for the store's details step by step and produces the SQL for someone to review. It never connects to the live database itself, so a typo can't go straight into production.
Day-to-day fixes
Much of the work is small and constant. Repair tracking now shows the right details for jobs that are in progress, the parts screen refreshes properly after a save, and each brand's warranty rules show on the right service reports. None of these are headline features, but they're the screens staff use all day.
Keeping it secure
Update, October 2026: when the PHP2Shell vulnerabilities were announced, the system's PHP services were patched within two days. One legacy component still runs on PHP 5.6, which has no patch. It stays behind a login while we plan its migration. The group's main website was also moved to a modern PHP 8 container with its own rollback. Read how we handled it.