5 Stages From Signed Contract to Deployed Client MVP

By Lazar Milicevic · Published July 19, 2026 · 7 min read

A solo builder watches a four-hour Claude Code course, opens the terminal, and two weeks later has a half-built todo app and zero paying clients. The tool isn't the problem. The missing piece is a delivery loop — the repeatable path from a stranger sending money to a working system in production. Here's the five-stage pipeline I run every week: three live products, real clients, one laptop, about $45/mo in Claude spend per active project.

Stage 1 — The one-page scoping doc that kills feature creep

Before any code, before any repo, I write a one-page markdown spec. Five sections, thirty-minute call, non-negotiable. If a prospect can't fill it out with me live, they're not ready to be a client — and I'd rather find that out on a call than three weeks into a build.

Here's the exact template:

# [Project] Scoping Doc

## Problem
One sentence. What breaks today?

## User
One sentence. Who suffers from the problem?

## Success metric
One number. "Cut invoice-send time from 12 min to under 2 min."

## Constraints
Budget, deadline, stack lock-ins.

## Out of scope
The 5-10 things we are NOT building in v1.

The Out of scope section is the one that saves the project. A client will ask for Stripe, QuickBooks sync, a mobile app, and multi-currency in the same breath. Writing "not in v1" next to each one on the call — with them nodding — kills roughly half the rebuild requests before they exist.

This file becomes the first message in a new Claude Code project. Not as a prompt, as context. I tell Claude: this is the spec, do not deviate. That single habit has saved me around 40 hours of rework this year across the three products.

Stage 2 — Repo scaffold and a CLAUDE.md under 100 lines

Once the spec is approved, I ask Claude Code to generate exactly two things: a CLAUDE.md at the repo root, and a folder structure that maps 1:1 to the spec. Both come out in about two minutes. I commit and stage 2 is done.

The CLAUDE.md is not a novel. Mine are under 100 lines. It answers five questions:

• What does this project do?
• What stack does it use?
• What command runs the tests?
• What command deploys?
• What are the three or four hard rules? (e.g. never touch /migrations without asking)

Here's a real trimmed example from an invoicing build:

# CLAUDE.md

## Project
Invoicing SaaS for US freelancers. PDF generation, Stripe payments,
IRS-compatible line items.

## Stack
- Next.js 14 (app router)
- Postgres via Prisma
- Stripe API
- Vercel for deploy

## Commands
- Test: `npm run test:fast` (must pass in <30s)
- Deploy: `./scripts/deploy.sh` (includes rollback)

## Hard rules
1. Never modify `/prisma/migrations/*` without asking.
2. Never touch `.env*` files.
3. Every PR must include a changelog entry.
4. Tax logic changes require a test case first.

Claude reads this every session. It's the difference between an assistant that remembers your project and one that reinvents it every morning.

The folder structure comes straight from the spec. If the spec says invoicing, I get:

/pdf        → invoice rendering
/db         → Prisma schema + queries
/api        → route handlers
/lib/tax    → tax calc (isolated, testable)
/scripts    → deploy + rollback

No utils/ catch-all. No helpers/. Every folder maps to a noun from the spec.

Stage 3 — 20-minute build sprints, not 2-hour vibe-coding sessions

My rule: 20-minute sessions on one vertical slice at a time. Prompt → review diff → run tests → commit. Then stand up. This is where most builders go wrong: they type "build the whole app" and let Claude run for two hours. That's not building, it's gambling with your context window.

Claude Code is fast, but context degrades the longer a session runs. Short sessions with narrow goals produce cleaner code than marathons. When something breaks, I know exactly which 20-minute chunk did it.

A "vertical slice" means one feature the client can actually see and click:

• Good slice: "User uploads a CSV of line items → sees them in a table → clicks Generate PDF → gets a downloadable file."
• Bad slice: "Set up the database layer." (invisible, no client value, spirals)

What a real sprint looks like

• 0:00 — Paste the slice description + relevant file paths. Ask for the diff, not the code.
• 0:03 — Read the diff line by line. Reject anything that touches an unrelated file.
• 0:08 — Apply, run npm run test:fast.
• 0:12 — If green, commit with a message a human can read. If red, one more prompt with the failing output.
• 0:20 — Stand up. Water. Next slice.

On a good day I ship 8-10 slices. On a bad day I ship 3 and I still know what I built.

Stage 4 — Guardrails: the stage nobody teaches

Once a paying client is on the other end, Claude cannot be allowed to break production. I set up three things on every project: pre-commit hooks, a protected paths list, and a fast test suite that catches business-logic regressions. This is the unglamorous stage that separates a studio from a hobbyist.

1. Pre-commit hook. Claude Code lets you run scripts before actions. If lint or tests fail, the commit is blocked — Claude can't merge broken code even if it wants to.

#!/bin/bash
# .git/hooks/pre-commit
set -e
npm run lint
npm run test:fast

2. Protected paths in settings. Migrations, env files, deploy configs. Claude has to explicitly ask before touching them.

{
  "protectedPaths": [
    "prisma/migrations/**",
    ".env*",
    "scripts/deploy.sh",
    "lib/tax/**"
  ]
}

3. A 30-second critical-path test. On the invoicing product this test:

• Generates a sample invoice
• Verifies the PDF renders without errors
• Checks totals math (subtotal + tax = grand total, to the cent)
• Checks tax calculation against a table of known cases

def test_invoice_critical_path():
    inv = generate_invoice(sample_line_items)
    assert inv.pdf_bytes is not None
    assert inv.subtotal + inv.tax == inv.total
    assert round(inv.tax, 2) == round(inv.subtotal * 0.0875, 2)  # NY

Claude once tried to "clean up" the tax logic and got a rounding case subtly wrong. The test caught it before a single client invoice went out. That is what guardrails buy you: the freedom to move fast without breaking the thing paying your rent.

The three-guardrail checklist

• Pre-commit hook that blocks broken code
• Protected paths list for anything a bad diff could nuke
• <30s test suite covering the one thing the business cannot get wrong

Stage 5 — Handoff: the deploy script and the plain-English changelog

This is where solo builders bleed clients. You ship, you deploy, and then the client emails daily asking what changed. My fix is two files: a one-command deploy script Claude wrote itself, and a changelog Claude updates on every merge in plain English — not commit messages.

The deploy script includes rollback out of the box:

#!/bin/bash
# scripts/deploy.sh
set -e
PREV=$(vercel ls --prod | head -1 | awk '{print $1}')
echo "Previous prod: $PREV (rollback: vercel rollback $PREV)"
npm run test:fast
vercel deploy --prod

The changelog is the piece clients actually read. Not fix: typo in tax handler. Human sentences:

## 2026-07-18
- Invoices now show the tax rate on a separate line for clarity.
- Fixed a bug where invoices over $10,000 rounded incorrectly.
- Added a "Duplicate" button on the invoice list page.

## 2026-07-15
- New: bulk export invoices to CSV for your accountant.
- The dashboard now loads about twice as fast.

When the client emails "what's new this week?", I forward three bullets. They read it in 20 seconds and go away happy. That's the entire retention system.

The numbers behind the loop

Five stages. Roughly three days from signed contract to deployed MVP for a scoped-tight project. Claude spend runs around $40-50/month per active project. One person, three live products in parallel, without burnout.

Nothing here is special. The loop is repeatable. Every new client drops into stage 1 and moves through the same pipeline. That's what makes a one-person studio actually run instead of just look good on LinkedIn.

Where bizflowai.io fits

The delivery loop above is what I run for custom builds. For clients who don't need bespoke code — the ones who just need invoicing, lead follow-up, or client onboarding automated this week — bizflowai.io is the productized version of stages 1, 4, and 5: scoped workflows, guardrails already wired in, and a plain-English activity log the business owner can actually read. Same philosophy, no three-day build cycle required.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.