Auckland, New Zealand
Ben Gao
Software engineer & consultant
Cloud, integrations, ecommerce
I build and repair the systems a business runs on: the web platform, the seams between it and everything else, and the cloud underneath. Most of my recent work has been ecommerce — Shopify and BigCommerce talking to ERP, point of sale and payments, so stock and money agree — but the same problems turn up wherever a business depends on software it did not write. Lately much of that code is written alongside coding agents, which makes the record of why something was built matter as much as the code itself. Nearly four years of it inside New Zealand retail.
Where I help
Experience
I work across the product and the systems around it: the code, the agents now writing a good share of it, the seams between systems, and the cloud underneath. Ecommerce is the domain I know deepest — not the only one I work in.
The interface, the API behind it and the data model underneath, built as one thing rather than three. Usually TypeScript, React and Node, working from the schema up so the screens are only as complicated as the job actually is — and the product still behaves when a real customer uses it in a way nobody planned for.
- Web applications in TypeScript, React and Next.js
- APIs and data models shaped like the business, not the framework
- Interfaces that do not come with a manual
I build with coding agents, and I build for them. The hard part is rarely the code: a session settles something, the tab closes, and the reasoning goes with it, so the next agent works it out again and sometimes lands somewhere else. The record goes in the repository instead — requirements, trade-offs and open questions as Markdown beside the code, read before anything gets written — with tooling that keeps it current.
- Coding agents briefed from the repository, not a lost conversation
- Model output checked against a schema before a customer sees it
- Generation rate-limited and queued, so busy weeks stay affordable
The expensive part of a business sits between its systems: stock in three places, orders keyed twice, a nightly export holding it together. I connect them directly, with APIs and events rather than spreadsheets. Ecommerce is where I have done most of it — Shopify and BigCommerce into ERP, point of sale and the warehouse, so a sale becomes a pick within minutes. The same joins produce the month's numbers, so reporting reads the live systems rather than a copy of them.
- Shopify and BigCommerce connected to ERP, PoS and warehouse
- Stock and fulfilment that update within minutes, not overnight
- One set of numbers, traceable back to the system that made it
If the connection drops halfway through a payment, nobody should end up charged twice. I build the payment layer — mostly Stripe — so retries settle once, refunds land where they should, and finance can trace any transaction back to the order it came from.
- Stripe connected end to end
- Retries that cannot charge a customer twice
- Any transaction traceable back to its order
Replacing a business-critical system in one go is how these projects fail. I move it across in stages, keeping the old one running until the new one has proven itself — containers and infrastructure as code on Google Cloud, with running costs that track demand instead of a peak nobody hits.
- Change in stages, with no shutdown weekend
- Google Cloud, as a certified Associate Cloud Engineer
- Running costs that follow demand, not peak guesswork
Business systems do not keep office hours, and neither do the failures. I set systems up to recover on their own, ship changes daily behind automated checks, and keep enough of a record to explain an incident afterwards — with customer data masked and access limited to the people who need it.
- Failures that heal without waking anyone
- Daily improvements, checked before they ship
- Customer data masked, access limited and auditable