An example of what a build leaves behind: a document a team can build against, a board can sign and a vendor can quote from. This one was written for Haypartido, alongside the code, the shipped apps and the test harness. Flip through it here, or open the PDF.
One example of the documentation an MVP engagement leaves behind, with Haypartido as the worked case. Numbered requirements with traceability, process maps, user stories with acceptance criteria, C4 architecture views, an entity model and data dictionary, an API contract with worked payloads, sequence and state diagrams, payments and identity design, operations and runbooks, test cases and UAT results, a delivery plan, a go-live runbook, RAID and decision logs, and a handover inventory. It sits alongside the code, the shipped apps and the test harness.
The pack is the part that fits on a page. A whole-product build hands over all six of these; a fixed-price project hands over the ones in its scope. What you receive is written down before we start and listed in the handover inventory at the end.
The delivery pack shown here
A document like this one: requirements, architecture, data model, API, tests, runbooks and the decisions, so nothing lives only in someone's head.
The code
Repositories with the history intact, build and deploy scripts, environments and configuration, in your accounts from day one.
The product, live
The apps in the stores, the web app and the consoles, running on your infrastructure and your payment account.
The test harness
Unit tests, end-to-end checks and the QA record, so the next change is as safe as the first release.
Runbooks and handover
How to operate it, what to watch, who holds which key, and the backlog we would pick up next.
Design files
Wireframes, the shipped screens and the brand where we built one, in the tools your team already uses.
Every page carries a Sample deliverable stamp. Written for Haypartido, a brand we built, and lightly edited for publication. The product and its rules are as shipped; counts, dates and amounts in the pack are illustrative, and the screens show placeholder data. One example, not a checklist: what you receive is agreed in scope before we start, listed in the handover inventory at the end of the pack, and often runs to more than this.
How it was built
The diagrams do the explaining.
Process maps, architecture views, sequence and state diagrams, the data model and the delivery plan, drawn from the product and kept in the pack so they never drift from it.
Sell a seat, as a swimlane. To-be process from a free hour on the diary to a Monday payout, across venue, player, system and money. Figure 2 · section 4Container view. C4 level 2: web app, mobile app, consoles, the API with the engine and scheduler in-process, and the stores. Figure 5 · section 8The ship pipeline. One command, and every step refuses to continue on failure: gate, build, deploy the API, then web, then mobile OTA, then verify. Figure 18 · section 18
Ten figures from the pack
Swimlanes, C4 views, entity model, sequences, state machines, test levels, the plan and the ship pipeline.
45 pages
