Ship the Thin Slice: How to Scope a 14‑Day MVP That Actually Moves the Needle

A 14‑day MVP isn’t magic; it’s constraint. The trick is to ship a thin slice - the minimal vertical cut that proves value end‑to‑end: auth → one core flow (happy path) → payments/analytics → deploy. This post shows exactly how I scope that slice so it’s shippable in two weeks and useful on Day 14.

TL;DR

• Decide one user, one job‑to‑be‑done, one success metric for 30 days.
• Map the happy path (one way to win). Edge cases → Backlog.
• Choose defaults (hosted DB, proven libs, minimal settings).
• Define acceptance criteria for each step; timebox unknowns.
• Build auth → core flow → payments/analytics → deploy + docs.
• Demo on Day 14; queue Sprint 2 with prioritized backlog.

1) One user • One job • One metric

User (who)

Pick a single primary persona who gets immediate value (e.g., “Property manager at small portfolio”).

Job (what)

Write a one‑sentence JTBD: “When [situation], the user [does] to get [outcome].”

Metric (proof)

Define success you can observe within 30 days (sign‑ups, completed flows, paid transactions, scheduled demos).

Example: “10 qualified sign‑ups, 7 completed core flows, 2 paid transactions.”

2) Map the happy path (one way to win)

Write 5–7 steps from “first contact” to “moment of value” (the point where the user would say “this helps”). Ignore fail states for now.

Visit → Sign up → Create [thing] → Review → Pay/Confirm → See result

Keep it linear. If a step branches, pick the most common branch.

3) Define the “moment of value”

Ask: What screen or event proves the core job happened?

• Marketplace: checkout success (order created)
• AI tool: output preview saved/shared
• SaaS tool: entity created and visible to another user
• E‑commerce add‑on: payment confirmed and basic analytics recorded

Your MVP should race to this moment with the fewest possible screens.

4) Choose defaults (kill the debates)

Defaults that keep 14 days realistic:

• Infra/DB: hosted Postgres (or your hosted DB of choice) + migrations.
• Auth: Email/OAuth with sessions; roles only if strictly required.
• Payments: Stripe (or platform default) early (test → live).
• Analytics: 5–8 product events that map your happy path.
• UI: a11y‑friendly component library; minimal settings.

If a decision takes >30 minutes, pick a reversible default and move.

5) Thin‑slice deliverables (the 14‑day package)

• Auth - sign up/in, stay signed in, sign out; basic authorization guard.
• Core flow - one happy path from create → confirm.
• Payments/analytics - take money (if relevant), record events.
• Integrations (if required) - exactly what the happy path needs.
• Deploy + docs - prod URL, README, system sketch, ops notes.
• Backlog - all the “great ideas” parked for Sprint 2.

6) Acceptance criteria (so “done” is done)

For each step, define a check you can demo.

Auth ACs

• User can sign up/in; session persists across refresh.
• Protected routes redirect unauthenticated users.

Core flow ACs (example: marketplace)

• Create listing with title/price/media; appears in list and detail.
• Add to cart → checkout → order record exists with status=paid.

Payments ACs

• Test card succeeds; order status updates; receipt/log created.

Analytics ACs

• Events exist for view → start → complete; simple query shows conversion.

Deploy/docs ACs

• New developer can run the project with README alone (fresh‑laptop test).

7) Put everything else in Sprint 2

Common backlog items:

• Notifications matrix and templates
• Fine‑grained roles/permissions
• Settings, theming, imports/exports
• Advanced reporting
• Edge‑case flows

Backlog isn’t a graveyard - it’s how you protect speed without losing ideas.

8) Thin‑slice templates by product type

A) B2B SaaS

• Happy path: Invite → Create entity → Share/Use → (Pay if needed)
• Deliverables: Auth, entities (create/view), sharing (basic), analytics, optional Stripe
• Moment of value: Entity viewed/used by another real user
• Example: Auth → Create Project → Add Item → Share Link → See Activity

B) Marketplace

• Happy path: List item → Discover → Checkout
• Deliverables: Create/list/listing detail, cart/checkout, order record, analytics
• Moment of value: Successful checkout
• Example: Create Listing → Listing Detail → Add to Cart → Pay → Order Record

C) AI Wrapper

• Happy path: Input → Model call → Review → Save/Export → (Paywall optional)
• Deliverables: Prompt/input UI, async job or streaming, output preview, save/export, basic credit or paywall
• Moment of value: Saved/exported output that user can use/share
• Example: Auth → Input → Generate → Preview → Save/Export → (Pay)

D) E‑commerce Add‑On

• Happy path: Product page → Add to cart → Pay → Confirmation
• Deliverables: PDP, cart/checkout, order capture, analytics, simple admin seed
• Moment of value: Payment captured + confirmation page
• Example: PDP → Cart → Checkout → Payment Success → Order Record

9) The Feature Kill Matrix (use this to say “not now”)

Include now only if the answer to both is “yes”:

• Does it directly enable the moment of value?
• Will it be demonstrated in the Day‑14 demo?

If not, backlog it. Example: “bulk import” rarely enables a Day‑14 demo.

10) Example thin‑slice spec (copy/paste)

Goal: 10 buyers complete checkout in 30 days.

Deliverables (Sprint 1):

• Auth (email/OAuth), create listing (title, price, media)
• Listing list/detail, add to cart, checkout (Stripe)
• Events: listing_viewed, checkout_started, order_paid
• Deploy, README, ops runbook

Backlog (Sprint 2): notifications, admin analytics, CSV import, theming

Risks: media upload perf → compress client‑side; price edits → lock price at checkout

11) Demo script (5 minutes)

• Create account → sign in
• Create listing “X” ($Y) with one image
• Open listing detail → add to cart → pay (test card)
• Show order record + confirmation
• Open analytics page (3 events visible)
• Show docs/README → show production URL

If you can’t demo it in five minutes, the slice is too wide.

12) Definition of Done (DoD)

• User can complete the core job without help (happy path).
• Payments (if relevant) work; an order/record exists.
• Analytics show start → complete counts.
• Docs exist; deploy is live; you own repo + infra.
• Backlog is prioritized (Sprint 2 plan ready).

13) Common pitfalls (and fixes)

• “Let’s add roles, notifications, settings first.” → No. Ship the job, not the knobs.
• “We need perfect design before build.” → No. Use accessible defaults; refine post‑demo.
• “Edge cases keep breaking the timeline.” → Happy path only in Sprint 1; document edges.

14) What this looks like with me (Week One Labs)

• Day 1: lock user/job/metric, map happy path, sign a one‑page Scope Card.
• Days 2–13: auth → core flow → payments/analytics → integrations (if needed).
• Day 14: demo + deploy + docs. You own repo and infra.

Price: Intro sprint $3,999 (fixed fee; 2–3 core features). If I miss agreed scope due to me, I add a free week.

Key Takeaways

• Thin slice = auth + one core flow + payments/analytics + deploy.
• If it doesn’t make the Day‑14 demo better, it’s Sprint 2.
• Define acceptance early; pick defaults; timebox unknowns.
• Five‑minute demo = you scoped it right.