Build log: turning interview notes into client-ready SOPs

This is the first entry in an ongoing series where we document our own builds the way we document client processes. Fair is fair. A video walkthrough of this build is being recorded and will be embedded here when it's edited.

The problem

An assessment interview produces messy, valuable raw material: notes, pain-point flags, process captures with volumes and minutes attached. The deliverable a client pays for is the opposite of messy — a numbered SOP with owners, systems, steps, and failure points. Getting from one to the other by hand took hours per process. Multiply by forty processes per assessment and the math stops working.

The pipeline

Our internal assessment studio generates one artifact per request:

1. Context assembly. Everything known about the engagement — company profile, tech stack, interview answers, process captures — is compiled into a single structured context. Every generator reads from the same assembled context, so an SOP never contradicts a finding.
2. Generation. Claude drafts the SOP against a versioned prompt. Prompts are versioned like code, because they are code: when the prompt changes, we can say exactly which deliverables were produced under which version.
3. Founder review. Nothing reaches a client document without explicit approval. The review screen exists to make rejecting easy — a generated draft that's 90% right and 10% wrong is worse than no draft if the 10% ships.

The guardrail that matters most

The model is never allowed to invent dollar figures. All ROI math is computed in ordinary code from client-provided volumes and rates; the model may only propose conservative hours-saved estimates, and only when there's a numeric basis for them. If the data isn't there, the ROI line is omitted entirely.

This split — model drafts prose, code does arithmetic, human approves everything — is the whole design philosophy in one sentence.

What surprised us

• Structured capture beats better prompts. The single biggest quality jump came from making the interview capture more structured, not from prompt engineering. Garbage in, eloquent garbage out.
• Rejection has to be cheap. Early versions made editing a generated draft easier than rejecting it. That's backwards; it nudges the reviewer toward polishing wrong content.
• Print is the hard part. Getting a generated document to break cleanly across PDF pages took longer than the generation pipeline itself.

More build logs — with video — as the studio grows.