Spec to Staging in 4 Days: My Solo Client Pipeline

By Lazar Milicevic · Published June 25, 2026 · 8 min read

You sign a client on Monday. By Thursday your own SaaS is throwing 500s because you edited a shared utility file at 1AM trying to hit their deadline. Or you ship the client work clean but your own products went two weeks without a commit. That's the real bottleneck of running a one-person business with Claude Code — building is easy, delivering paid work without your own systems collapsing is the hard part.

Here's the exact pipeline I run: three live products in production, six client projects per quarter, zero hires, one Claude Code workspace. Average delivery from signed spec to staging URL is four working days.

The workspace layout that prevents cross-contamination

Two top-level directories at the workspace root: products/ and clients/. That single rule is what keeps client code from poisoning the things I own. Products holds the three SaaS apps I operate. Clients holds every paid engagement, each in its own folder named by client slug and quarter (clients/acme-q2-2026/).

A single CLAUDE.md sits at the workspace root. It's the brain Claude Code reads before any session starts, and it tells the agent three things:

# Workspace Rules — read before any action

1. WRITE SCOPE
   You may only write to the directory passed in the current session prompt.
   Default write scope = current working directory.

2. SHARED LIB (/lib)
   Read-only by default. Contains: pdf_parse, auth, mailer, db.
   If you are about to modify ANY file under /lib, STOP and ask the
   operator for explicit confirmation. Do not proceed without "yes /lib ok".

3. FORBIDDEN CROSS-REFERENCES
   - clients/* MUST NOT import from products/*
   - products/* MUST NOT import from clients/*
   - Both MAY import from /lib (read-only)
   If you detect such an import, refuse and surface the violation.

The /lib folder holds battle-tested utilities — PDF parsing, auth wrappers, email senders, database connectors. Both sides can read from it. Writes require a typed confirmation. Claude respects the stop-and-ask rule reliably in my experience; the times it didn't, the cross-reference check caught the violation downstream.

Why the split matters in practice

• A bug in a client repo can't reach a product import path
• Refactors in /lib are forced through a deliberate review gate
• Onboarding a new client is a mkdir and a scaffold prompt, not a workspace migration

Day 1: Intake → signed spec → scaffold plan

The client sends a Loom, a Google Doc, or we hop on a call. Everything lands in a single file: clients/<slug>/intake.md. Raw dump, no formatting required. Then I run a three-prompt chain in the same Claude Code session.

# Prompt 1 — problem statement
"Read intake.md. Produce a one-page problem statement in plain English.
No jargon. No solutions yet. Just: who, what's broken, what good looks like."

# Prompt 2 — technical spec
"From the problem statement, produce technical-spec.md with:
- Explicit IN/OUT of scope (two bulleted lists)
- Integrations (named services, API versions)
- Risk section (top 5 things that could blow up)
- Acceptance criteria (testable)"

# Prompt 3 — scaffold plan
"Turn technical-spec.md into scaffold.md.
List every file to create, with a one-line purpose.
Group by: /api, /db, /jobs, /ui, /tests. No code yet."

By end of day one I have a spec the client signs in DocuSign and a scaffold plan ready to generate. The signed spec is the contract — if they want something not in scope, it's a change order. According to the PMI Pulse of the Profession 2024, scope creep affects 34% of projects and is the leading cause of failure on small engagements. A signed one-page spec kills it before it starts.

Days 2–3: The subagent QA loop

This is where most builders burn out by trying to one-shot every feature. I don't. I use what I call subagent-driven QA, and it's the single biggest quality multiplier in my pipeline.

The main agent writes a feature. Then I spawn a fresh subagent with one instruction:

You are a skeptical senior code reviewer who has never seen this
codebase before. Read the diff below. Find three things that will
break in production. Be specific: file, line, failure mode.

Do not be polite. Do not suggest style fixes. Only production-breakers.

The subagent comes back with real issues every single time. Patterns I see most:

• Hardcoded values that should be env vars (API keys, region strings, retry counts)
• Missing error handling on outbound HTTP — no timeout, no retry, no circuit breaker
• Race conditions on shared resources (job queues, cache invalidation, webhook idempotency)
• N+1 queries hidden inside ORM helpers

I feed the findings back to the main agent and we patch. This loop runs six to ten times across two days. Anthropic's own research on subagent patterns showed multi-agent setups with a coordinator-plus-fresh-context-reviewer outperformed single-agent runs by roughly 90% on complex research tasks. The mechanism that matters here is the same: a reviewer with no prior context catches what a tired main agent rationalizes away.

Deployment to staging is one command:

./deploy.sh staging
# builds, runs migrations, pushes to staging env,
# posts URL to the shared Slack channel with the client

The deploy script was written by Claude, customized per stack, but always exposes the same interface. I don't have to remember which client uses Fly.io, Railway, or a Hetzner box.

Day 4: The handoff package that gets you referrals

Most freelancers skip this day. It's the one that gets you referred. I prompt Claude to generate three artifacts and I review each one before sending.

1. README for a non-technical founder. Architecture in plain English. What each service does. How data flows. No diagrams full of UML — just numbered steps a founder can read on their phone.

2. Access doc. Every credential, every dashboard, every third-party account, with login instructions and the email used to register. This is the difference between a client who can fire you cleanly and one who's chained to you forever. I want them to be able to fire me. It's why they hire me again.

3. Loom walkthrough script. A teleprompter-style narration I read while screen-recording. Five to eight minutes covering "here's where to add a user, here's where to see errors, here's what to do if something breaks at 2AM."

# loom-script.md (excerpt)

[0:00] Hi <client>, this is the walkthrough for the staging deploy.
[0:15] Open <staging-url>. Log in with the admin email from access-doc.md line 4.
[0:45] Left sidebar — "Jobs" is where you'll see every PDF processed.
[1:20] If a job goes red, click it. The error message is the actual stack trace.
[1:50] To add a teammate, go to Settings → Users → Invite. Costs nothing extra.
...

A clean handoff pack — not a zip file and a prayer.

The three guardrails that keep client code from poisoning your products

These exist because I broke each rule once and paid for it.

Guardrail 1: Separate git remotes. Every client folder has its own remote. Products have their own. No shared repository, ever. If I accidentally commit client code while in the wrong directory, it physically cannot end up in a product repo — the remote doesn't exist there. git push fails loudly.

Guardrail 2: Environment isolation. Each client folder has its own .env and its own dependency lockfile. No global pip installs. No shared virtualenv. CLAUDE.md tells Claude to activate the local environment before running anything:

# always run from inside the client folder
source .venv/bin/activate
# or: nvm use $(cat .nvmrc)

This also means a client can ask for Python 3.11 with a specific Pydantic version while my product runs 3.12 with the latest. They never collide.

Guardrail 3: The daily product check. Every morning before I touch any client work, I run one command that hits health endpoints on my three products and pushes the result to my phone via Pushover:

./bin/morning-check.sh
# GET /health on each product
# checks: db connection, queue depth, last successful cron
# posts: 🟢 fakturko | 🟢 una-intel | 🟢 bizflowai.io  (or 🔴 with details)

If anything is red, products come first that day. The client work waits. Stripe's 2024 developer productivity report found that engineers lose roughly 33% of their week to maintenance and bad tooling — for a solo operator running their own SaaS plus client work, that number is the difference between profitable and underwater. A two-minute morning check prevents the 4-hour fire drill.

What this pipeline actually costs

Real numbers from the last quarter, six projects:

The Claude spend is the only line item that scales with project complexity. Everything else stays flat because the workspace structure does the heavy lifting.

Where bizflowai.io fits in this workflow

The intake-to-spec chain and the daily product health check are exactly the kind of glue work bizflowai.io already automates for solo operators and small teams — connecting client intake forms to a structured spec document, posting deploy URLs to shared Slack channels, watching health endpoints and routing alerts to the right channel based on severity. If you're running multiple projects out of one workspace and the manual coordination is what's eating your week, that's the wedge where the automation pays for itself in the first month.

The takeaway

The reason most solo builders can't run client work alongside their own products isn't talent. It's that they don't have a workspace contract. CLAUDE.md as the brain, two top-level directories, separate remotes, a daily health check. None of it is fancy. All of it is enforced. Four days from signed spec to staging, repeated six times a quarter, without my own SaaS catching fire — that's what the structure buys.

Start with the directory split and the CLAUDE.md file. Add the subagent reviewer next. The handoff package and the morning check are the last 10% that turns one-off clients into repeat ones.

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.