Written against a spec packet, before the code

The problem

A service business runs on a group text thread and a stack of paper work orders. Intake, dispatch, work, invoicing, and payment each live in someone's head, and the seams are where work is lost — a summer emergency queues behind a routine tune-up because whoever answered ranked by who called first, and the customer learns their wait time by phoning to ask. The domain is genuinely fiddly: job types carry different urgency, invoices carry a jurisdiction-specific tax and prefix, and five departments need to know about the same event.

The build

The repository is organised as if the business had already delivered a spec packet, and the documents are treated as received rather than as a summary written after the fact. An owner brief captures the semantics — what finished actually feels like in the shop. From that, a product document fixes scope and actors, a requirements document numbers every function and non-function requirement with a Must/Should/Could/Won't priority and stable IDs that implementation marks off rather than renumbers, and architecture, domain, and API documents follow. A sequence diagram covers the full job lifecycle from intake through dispatch, work, invoice, payment, and notification. A class diagram names the nouns — Lead, Job, WorkOrder, Invoice, Payment, Notification — that the models then implement. Seven actors are distinguished, including a customer with no login and a payment processor, because each has a different view of the same job. The domain rules that matter are written down before they are coded: emergency work ranks ahead of maintenance, a technician cannot be double-booked into the same arrival window, and every mutation emits the notification its department depends on.

• —Numbered FR/NFR requirements with stable IDs and a Must/Should/Could/Won't priority
• —Sequence and class diagrams naming Lead, Job, WorkOrder, Invoice, Payment, Notification
• —Seven actors modelled, including a no-login customer and a payment processor

The outcome

The output is a codebase with an explicit, reviewable contract behind it, and requirements traceable to the code that satisfies them. Honest status: intake and invoice paths have first-pass code, while scheduling, work orders, payments, and notifications are stubbed with owner notes attached. The value of the exercise is as much in the documents as the code — the sequencing, the actors, and the tax and jurisdiction rules were settled before anyone wrote a route.