A queue-management system - architecture as the deliverable (2025-2026)
The situation
A client's queue-management vendor was raising subscription pricing and forcing technical upgrades on them. They asked whether the capability could instead be built into the platform ecosystem I already ran for them. Replacing the vendor was the easy read; the harder question was whether an aftersales service lane - booking, check-in, reception, service advisers, workshop, parking, collection, each with its own operators, shortcuts and exceptions - could be modelled properly rather than merely digitised.
The long discovery
I walked the operation as a customer, then as each role: call centre, reception, service adviser, workshop, the parking vendor. What that surfaced was not features but exceptions - the key-drop customer who must be called to the counter before anything can proceed, the vehicle that arrives on a tow truck with no owner present, the car moved twice inside the workshop by technicians who are not the parking crew, the walk-in who joins a queue meant for a different department entirely and waits an hour for a number that was never coming.
What I built
A full working prototype - twenty-four modules, every role, every state - architected and built by me with AI, and behind it a documentation corpus of roughly 86,000 words across twenty-five documents. Its shape matters more than its size. Every module has a verify list written from the shipped build rather than from the spec, so the documentation describes what exists rather than what was intended. A reconciliation decisions log - the largest document in the corpus - records what was decided, why, and what it supersedes, and acts as the arbiter when two documents disagree. Superseded documents are not deleted but formally retired with the reasoning attached, because a stale plan written in the future tense is more dangerous than an obviously old one. And every behaviour is marked as either client-specific configuration or core product, so the deployment can be delivered without the product becoming bespoke to it.
The judgment calls
Several were governance rather than engineering. Vouchers: the client wanted staff able to redeem on a customer's behalf; I held that this destroys the customer's ability to dispute, then designed the middle path - redemption on behalf permitted, but reason-logged and notified to the customer with a route to report it. Consent: I raised that a consent recorded once and honoured forever is not consent, and that both withdrawal and the right to change one's mind need machinery. Retention: anonymise at two years of inactivity rather than delete, so operational history survives without the person in it. Every abnormal operator action - a queue bump, a reassignment, an override - requires a reason and is logged, because the point of an audit trail is the dispute you have not had yet. I also declined to generate a document the client's own system already produces, capturing its reference number instead: two sources of truth is worse than one inconvenience.
Outcome
Presented to the client's operational leadership and IT function, who described it as comprehensive and materially better suited to their business than the system it replaces. Feedback rounds are closed and the specification is signed off for build. The commercial position was structured deliberately: the core capability lands as an upgrade within the existing platform relationship at no additional cost, with the workshop-status extension scoped separately and priced as its own enhancement.
What this shows
The architecture, the discovery, the decisions and the handover artefacts were the deliverable - not the code. A system this size built solo, documented to the point where another team can pick it up cold, with the client-specific and productisable parts already separated. This is the clearest example I have of how I work: read the floor first, design for the exceptions, write down every decision and its reasoning, and leave behind something that does not depend on me being in the room.