Case 01 · Selected Work
Building against a system we did not own
A multi-role booking and ordering platform went live against an enterprise client's legacy ERP, with the API contract negotiated directly with the client's own engineers and every scope change signed off before it reached engineering.
- Role
- Lead Developer
- Capabilities
- Discovery · Integration · Stakeholder alignment
- Domain
- Enterprise booking and ordering platform
- Integration
- A client's legacy ERP, through an agreed API contract
Context
An agency delivery team building a reservation and on-site ordering platform for an enterprise client. The client ran its own engineering team and its own legacy ERP, which held the customer records. A first version existed and was not good enough; the agency wanted the second version to become its first reusable, resellable product, which is why the build came to me.
Problem and ambiguity
The client integrated in two directions at once: a user interface used for maintenance and templates, and an API surface carrying the work that mattered — ordering, cancellation, planning. That meant the contract had to match in both directions, precisely. And the client was still deciding its own business logic while we were meant to be building against it: it took weeks of discussion before we could agree what a single order even was. Material arrived late, responsibility for the delay moved around, and specifications reached engineering incomplete.
My role
Lead Developer. I owned the backend and the cloud delivery and coordinated the split between frontend, backend and cloud. I ran the API-contract negotiation directly with the client’s engineers. I built the complex, contract-defining flows of the customer-facing client myself and delegated the straightforward screens; where a screen did not match the contract, I fixed it. I mentored two frontend developers. An architect supplied the first version and stayed lighter on the second, handling parts of the cloud setup — that was not my work.
Discovery
Requirements arrived through the project manager; I classified them and broke them down. Several sessions a week with the client, daily standups internally. What actually fixed this project was a practice, not a tool: document the current process, draw the proposed flow, walk the stakeholder through it, and get a written confirmation before engineering starts. Framed as de-risking speed, not as engineering refusing to move.
Architecture and trade-offs
Customer records stayed on the client’s side; our platform carried the order flow anonymised — less data to hold, one less thing to negotiate. Because the definition of an order was still moving, I sequenced the build around it: everything that did not need sign-off was pre-built, and the parts that would change last were isolated, which bought the client time without idling the team. I also consolidated a sequence of create, update and delete calls that the client application had been orchestrating into a single backend endpoint — moving the business logic off the client and returning a response shaped to the interface’s needs in one round trip.
Implementation and integration
Reservation, on-site ordering, kitchen resource management, seat and location management, and QR scanning, across several operating roles. The customer-facing client in Vue 3, built alongside the backend it consumed. Integration with the client’s legacy ERP through the agreed API contract.
Production controls
The platform runs twenty-four hours — a reservation system has to accept an order at any time. The operational rhythm was designed so that everything a human must do lands inside working hours: the day’s reservations confirmed before the first customers arrive, the next cycle dispatched at midday, nothing requiring attention after close. Downtime raises an email alert. I stayed on after hours to run the backup and settlement myself so the next day’s reservations could proceed.
Impact
The platform went live and replaced the system it was built to succeed, running the client’s daily operation across three operating roles working from dashboards.
Reusable learning
When a customer is still deciding their own business rules, the engineering job is not to wait and not to guess — it is to sequence the build so the undecided part is the last thing you touch, and to make the decision visible enough that signing it off feels like progress rather than commitment.
Evidence pending
An anonymised architecture diagram would carry this case. A clean-room rebuild with a mock legacy ERP behind an adapter is specified as project P5 in the portfolio register; it is not built.