Goudplevier
Client login Book a call See pricing

Sample deliverable

The MVP Delivery Pack written for Haypartido, a brand we took from idea to the app stores. One example of the documentation an engagement produces, alongside the code and the product itself. What you receive depends on what was bought, and is often more than this. Use the section list to jump, the arrows to flip, or open the PDF.

Sample deliverable · 45 pages

Haypartido MVP Delivery Pack

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.

Where each product shows up

Requirements Packsections 2 to 7, Appendix BMVP in six weeks · whole productsections 8 to 17UAT and Go-livesections 16 to 18Dashboardsection 2.3 KPI tableAutomation Pilotsection 14 jobs and runbooks
Open the PDF
Haypartido MVP Delivery Pack, page 1 1 / 45

Jump to a section

  1. 1 to 2Executive summary, objectives and KPIs
  2. 3Scope, assumptions, constraints
  3. 4Business processes and decision table
  4. 5Functional requirements
  5. 6User stories with acceptance criteria
  6. 7Non-functional requirements
  7. 8Solution architecture and ADRs
  8. 9Data model and data dictionary
  9. 10API contract with worked examples
  10. 11Key interactions: sequences and states
  11. 12Payments design
  12. 13Identity, access and personal data
  13. 14Automation, operations and monitoring
  14. 15Screens: from wireframe to shipped UI
  15. 16Test strategy, UAT and results
  16. 17Delivery plan and ways of working
  17. 18Go-live: readiness, cutover, hypercare
  18. 19 to 21RAID log, decision log, handover
  19. AppendicesGlossary, traceability, notifications, config

What an engagement leaves behind

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.

The figures

Ten diagrams from the pack.

Click any figure to see it large. Each caption names the section it lives in.

Sell a seat, as a swimlane
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 4
Container view
Container view. C4 level 2: web app, mobile app, consoles, the API with the engine and scheduler in-process, and the stores. Figure 5 · section 8
Entity model
Entity model. The core model with crow's-foot ends: users, grants, venues, pitches, games, bookings, reservations, ledger, payouts. Figure 7 · section 9
Book and pay
Book and pay. The seat is held before the charge, the webhook reconciles, and the failure path releases the seat. Figure 8 · section 11
Wireframe to shipped screen
Wireframe to shipped screen. Three screens, each with the wireframe, the shipped UI and the annotations that changed between them. Figure 15 · section 15
Game state machine
Game state machine. Draft, published, then confirmed or cancelled at the deadline, and completed after kickoff plus duration. Figure 12 · section 11
Test levels
Test levels. Five layers, each with an owner, a trigger and an exit: unit tests, contract lints, the QA harness, browser walks and the owner walking production. Figure 16 · section 16
Job timeline around one game
Job timeline around one game. Every scheduled job placed on the clock relative to kickoff, from the warm-up nudge to the MVP ballot closing. Figure 14 · section 14
The ship pipeline
The 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
Seven-week plan by workstream
Seven-week plan by workstream. Definition, foundations, product, quality and launch, with the five milestones. Figure 17 · section 17

The product behind the pack

Seven boards on Haypartido: the problem, the players, the venue console, the money, the host, the platform and the brand.

Read the case study

Want something like this built for you?

Fifteen minutes is enough to tell whether it fits. No deck, no pitch.

Book a 15-min callSee pricing