Skip to main content

MVP Definition: The Vertical Slice That Proves the System

What This Concept Is​

For a capstone, the MVP (minimum viable product) is a single vertical slice of the system -- the smallest end-to-end path that exercises every architectural layer you are claiming. If your design doc says "web UI + API + database + export," the MVP must touch all four. If you cut the database out to make the MVP smaller, the MVP is lying. The MVP is not a feature list; it is the thinnest shaft of real behavior that runs on real infrastructure and proves your architecture actually holds.

The MVP is five things in writing:

  1. One user. Named. One role, not "users."
  2. One trigger. The specific action that starts the happy path.
  3. Happy-path steps. Numbered, 5-15 of them, each one touching at least one architectural layer.
  4. Success condition. Something observable -- a row in a DB, a file on disk, a 200 response, a scanned ticket turning green.
  5. Non-goals. Things explicitly not in the MVP, written down as pre-commitments.

It is built in week 2 (or earlier), deployed to a real environment, and tested end-to-end. Everything else -- extra features, polish, second contexts, convenience flows -- is built on top of a working slice or it is cut.

Why It Matters Here (In the Capstone)​

Eric Ries framed the MVP as the smallest thing that produces validated learning. In a capstone, the "learning" is architectural: does your chosen style actually work when every layer is hooked up? Does the datastore in ADR-002 actually serve the access pattern? Does the module boundary claimed in the C4 Component diagram survive contact with real code? You cannot know until one slice runs end-to-end.

The vertical-slice MVP also protects you from the most common capstone failure mode: horizontal building. You spend weeks 1-4 polishing the UI, weeks 4-5 wiring the API, and on week 6 you discover the DB schema is wrong or the deploy never worked. A vertical slice forces integration to happen early, when you can still change things. Every hour of horizontal work before a vertical slice exists is pre-week-5 debt.

Finally, the MVP is the artifact every downstream Cluster anchors to: characteristics (concept 07) are selected against it, the C4 diagrams (concept 11) must trace its path, ADRs (concept 12) justify its shape, fitness functions (concept 09) gate it, and the scope-cut rules (concept 14) promise never to drop it. Change the MVP and half the design doc re-opens.

Concrete Example(s) -- from a real capstone​

MVP A -- inventory service:

User: a warehouse staff member receiving a pallet of goods.

Trigger: the staff member taps "Receive" and scans a barcode.

Happy-path steps:

  1. Staff opens the web app (PWA) on a phone while on Wi-Fi.
  2. They tap "Receive" and scan a SKU barcode via the camera.
  3. They enter quantity 12.
  4. The app POSTs an append-only ScanEvent with a client-side idempotency key.
  5. Server persists the event; returns updated on-hand.
  6. App shows "On-hand now 42."
  7. Staff goes offline (airplane mode); scans another SKU, quantity 5.
  8. App queues the event locally.
  9. Wi-Fi returns; queued event flushes.
  10. Server de-duplicates by idempotency key; on-hand is updated.

Success condition: the ScanEvent audit log contains exactly one row per scan (no dup, no drop) and the derived on-hand matches.

Non-goals: user auth (single shared device for MVP), picking flow, daily reconciliation view, multi-warehouse, mobile-native client.

MVP B -- ticketing platform:

User: an event organizer.

Trigger: the organizer clicks "Publish event" with 200 tier-A seats and 100 tier-B seats.

Happy-path steps:

  1. Organizer fills event form; clicks Publish.
  2. Server creates Event + SeatTier rows in a transaction.
  3. A share URL is returned.
  4. Two test buyers open the URL in two tabs, each pick tier-A, and submit simultaneously.
  5. Server decrements seats atomically; one buyer wins each, one buyer's tier-A attempt fails if only 1 seat left.
  6. Winning buyer gets a QR code rendered in the browser.
  7. A door-scan simulator scans the QR and receives "valid, not previously used."
  8. A second scan of the same QR receives "already used."

Success condition: a t-test: 200 concurrent tier-A buys yield exactly 200 tickets, no oversell, no double-used scan.

Non-goals: email delivery, payment, seat maps, refunds, organizer auth, multi-event, door-scan offline mode (MVP is online-only; offline is v2).

MVP C -- finance aggregator:

User: the household primary (one person).

Trigger: the user uploads a CSV file for one checking account for one month.

Happy-path steps:

  1. User drops checking-2026-03.csv onto the web UI.
  2. Import pipeline hashes each row by (date, amount, memo) for idempotency.
  3. New rows inserted; duplicates skipped.
  4. Rules engine categorizes each row from rules.yaml.
  5. Uncategorized rows are tagged "uncategorized."
  6. User re-uploads the same file; import reports 0 new rows.
  7. User requests cashflow.md for March; system writes the file to ./reports/.

Success condition: cashflow.md matches a hand-reconciled spreadsheet to the cent, and re-uploading never changes the result.

Non-goals: multi-account, credit cards, encryption, web auth, recurring schedule (MVP runs on manual upload), browser-based visualization.

Notice what the non-goals are doing. They are not "nice to haves for later." They are "I will cut these ruthlessly when the MVP is at risk." Half the goal of writing non-goals is preventing scope creep on day 17 when you feel like adding a feature "because it's easy."

Common Confusion / Misconceptions​

  • MVP != Backlog. The backlog is "everything I might build." The MVP is "the one slice I will have working end-to-end by end of week 2." Conflating them gives a backlog with no finish line.
  • MVP != Prototype. A prototype is throwaway code that proves a concept. An MVP is the real first slice of the real system, built with real tests, real deploy, real observability. Throwaway code does not shape the architecture; an MVP does.
  • "Minimum" != "Cheap". A minimum viable ticketing platform still enforces no-oversell -- that is what makes it viable. Cutting the oversell guard makes it a prototype, not a minimum viable anything. Minimum is about scope, not about quality gates.
  • MVP != Demo. The MVP is the first real slice, built in week 2. The demo is what you show in week 6, possibly with features layered on top. The MVP is older, smaller, and more stable than the demo.

Relationship to the Walking Skeleton​

A "walking skeleton," in Alistair Cockburn's phrasing, is a thinnest-possible end-to-end implementation that exercises all the architecturally significant pieces -- UI, deploy, CI, DB, external integrations -- with near-zero business logic. Your MVP and the walking skeleton are usually the same artifact: the skeleton is the scaffolding (deployed, tested, observable), and the MVP is the skeleton with just enough happy-path behavior to constitute a viable user experience. Build the skeleton first; the happy path then grows into it rather than being bolted on at the end.

How To Use It (In Your Capstone)​

  1. Write the MVP by end of day 2 in the five-part format above. Commit to the design doc.
  2. For each happy-path step, label the layer it touches (UI, API, domain service, repository, store, queue, external call). A step touching no layer is UX detail -- move it out.
  3. Confirm every architectural layer in your Container diagram appears somewhere in the steps. If a layer has no step, either the MVP is too thin or the layer is speculative.
  4. Write at least 5 non-goals, naming features you want to build. Those are the ones most likely to blow up your scope.
  5. Build the walking skeleton in week 1-2: deploy, CI, DB connected, health endpoint green, one happy-path 200. Business logic follows.
  6. Cover the happy path with one automated test that runs in CI. This becomes your operability fitness function (concept 09).
  7. Freeze the MVP once committed. Changes require re-opening the design doc and updating ADRs. No stealth MVP-inflation.

Signs Your MVP Is Wrong​

  • The "success condition" is "I can demo it." That is not observable without you in the room.
  • A happy-path step is a UI polish ("the animation plays smoothly"). UI polish is not an MVP step.
  • Non-goals list is empty. Impossible -- start listing what you are not building.
  • The MVP cannot be deployed. Until it can be deployed, it is not an MVP; it is a local script.
  • The MVP happy path does not exercise the core subdomain. You are proving the wrong thing.

See also (integrative)​

The MVP compresses several prior-semester ideas -- vertical slicing, contract-first design, and thin-but-complete delivery -- into one artifact.

External references (curation-validated this session):

Check Yourself​

  1. Does your MVP touch every layer in your Container diagram? If not, which layer is speculative?
  2. Name one non-goal of your MVP and explain why it is explicitly cut.
  3. What is the observable success condition that a grader could check without asking you questions?
  4. If your MVP cannot be deployed today, what is the one missing piece -- and is it scheduled for this week?
  5. Does your MVP happy path run through the core subdomain (Cluster 2) or does it go around it?
  6. Which scope-cut rule (concept 14) protects the MVP when pressure rises? If none, you have not written the rule.

Mini Drill or Application (Capstone-scoped)​

  • Drill 1 (20 min). Write your MVP in the five-part format. For each happy-path step, name the architectural layer it touches. Merge steps that share a layer.
  • Drill 2 (10 min). Write 5 non-goals. Pick ones you actually want to build. Writing them here is how you commit, in advance, to cutting them.
  • Drill 3 (30 min, week 1). Build the walking skeleton: deploy one route, one DB write, one DB read, one health-check -- end to end -- to staging.
  • Drill 4 (60 min, week 2). Add exactly enough happy-path logic to turn the skeleton into the MVP. Nothing more. Add one automated test covering the full slice.
  • Drill 5 (15 min, end of week 2). Stand up the slice for a grader-simulation: read the success condition aloud; run the MVP; confirm the condition is observable without narration.

Source Backbone​

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.