The Build Pod Operating Manual

Credit-based delivery has a quiet asymmetry: two companies can buy the same pod, the same credits, the same team — and one gets triple the value. The difference is never the vendor's effort. It's the client-side operating rhythm: how requests enter, how fast scopes get approved, who shows up to demos, and whether acceptance means something.

This manual is the client-side playbook. It applies to any build-lane arrangement — including ours — because the mechanics of compounding delivery are the same everywhere.

01The four client-side roles

• ▸The lane owner. One person who owns the relationship, the backlog order, and the approval authority. Not a committee, not "the leadership team." Every day a scope waits for a group decision is a day of lane capacity burned.
• ▸The workflow owner (per build). The person who runs the workflow being automated. They write the request, answer the scoping questions, review the drafts, and decide acceptance. Builds without a workflow owner ship late and land wrong.
• ▸The access broker. Whoever can grant credentials, API scopes, and security sign-off — identified before the first build, not discovered during it. Access latency is the single most common source of lost delivery weeks.
• ▸The skeptic. Deliberately invite your most demanding operator to demos. Their objections during the build are free QA; the same objections after launch are adoption failures.

02Feeding the lane: backlog hygiene

A build lane starves without a groomed backlog. The hygiene is light but non-negotiable: every candidate written as a one-page request (trigger, walk-through, systems, judgment points, finish line — see DSP-09), ranked by the workflow audit math (FM-05), and re-ordered monthly in one 30-minute session.

The trap to avoid is the shiny-object shuffle: re-prioritizing mid-build because a louder idea arrived. A lane that switches targets mid-scope pays the context tax twice and ships half of two things. New ideas go on the list, the list gets re-ranked monthly, and the current build finishes.

03The approval discipline

Credit models put a written scope in front of you before work starts. That document is where the engagement is actually steered — everything after is execution. Treat scope review as a real meeting with the workflow owner present, and interrogate three things: the included list (is this the painful part?), the excluded list (can we live without these for v1?), and the acceptance criteria (would passing this genuinely mean it works?).

Then decide fast. A 48-hour approval rhythm keeps the lane full; a two-week one idles a third of your capacity. If a scope needs changes, mark them up in one pass — serial rounds of single comments are how a week disappears.

04Demos, acceptance, and the compounding loop

• ▸Weekly demos are steering, not spectating. The right attendees are the workflow owner and the skeptic, and the right behavior is trying it live — real inputs, awkward cases. "Looks good" is a wasted demo; "it breaks when the client name has a comma" is a great one.
• ▸Acceptance is a test, not a vibe. Run the acceptance criteria as written, with the workflow owner driving. If it passes, accept promptly — lingering "soft launches" blur the line between building and operating and stall the next build's start.
• ▸Feed usage back into the backlog. The first two weeks of real usage generate the best next requests you'll ever write: the edge case that queues for review too often, the adjacent step everyone now wants. Compounding lanes are steered by usage data, not by January's plan.
• ▸Review the lane monthly. One number ritual: credits spent, builds shipped, hours returned (per the ROI design in DSP-12), and the backlog re-rank. Twenty minutes. It keeps the engagement honest in both directions.