A working Claude Code prototype becomes a shipped product when six artifacts get added — eval set, model abstraction, fallback path, observability, runbook, on-call schedule. A senior engineer installs all six in roughly two weeks for $15-25K. The founder keeps the prototype, the prompts, and product control. The bridge is engineering work, not a restart. This piece names the six artifacts, the calendar and cost, the handoff conversation, and the operating model on the other side.
This piece builds on the DIY-with-AI manifesto, inside the broader idea-to-product manifesto. It sits next to the vibe-code-then-hand-off pattern and can I build an AI app with Claude Code. For the engineering bar the bridge targets, see the code review standard for prompt-bearing PRs.
Table of Contents
Why the bridge exists
A Claude Code prototype runs — accepts the real input shape, calls Claude Opus 4.8 with a prompt that captures the founder’s domain knowledge, returns the real output shape. It also has no answer to four questions a paying customer will eventually ask. What happens when Anthropic returns a 529 overload during a launch? How do you know last Tuesday’s batch was correct? When the system breaks at night, who restarts it? When Claude Sonnet 4.6 is deprecated, what changes?
Those four questions describe the gap between built and shipped. The 2025 Stack Overflow Developer Survey found 76% of developers use AI coding tools regularly while trust in accuracy fell from 43% to 35% year over year (Stack Overflow 2025). Universal use, falling trust. BCG’s “AI adoption in 2024” reports 74% of companies struggle to scale AI value beyond pilots — and the cited reasons are not capability but evals, observability, and operational discipline (BCG 2024). Anthropic’s “Building effective agents” reads the same way: an evaluation suite that captures user expectations beats any model upgrade (Anthropic, Dec 2024).
The bridge is not a rewrite. It is six discrete additions installed against a prototype the founder already owns.
The six bridge artifacts at a glance
| # | Artifact | What it is | Senior hours |
|---|---|---|---|
| 1 | Eval set | 20-50 labeled inputs with expected outputs and a scoring function, runnable in CI | ~12 |
| 2 | Model abstraction | A single interface the prompt code calls; the model identifier is a config value | ~6 |
| 3 | Fallback path | Defined behavior on model error, timeout, or eval-rejected output | ~10 |
| 4 | Observability | Structured logs, tracing, token and cost metrics, eval-pass-rate dashboard | ~16 |
| 5 | Runbook | Markdown naming every failure mode and a 3-step recovery for each | ~6 |
| 6 | On-call schedule | Named human, paging tool, SLA, rotation cadence | ~4 |
| Total | ~54 hours over ~2 weeks |
Hours calibrate to a single-feature prototype (one prompt, one or two tool calls, one endpoint) and scale linearly with feature count, superlinearly with agentic step count. At a US/EU senior rate of $200/hour, engineering prices at ~$10.8K plus $4-8K of fixed costs (observability vendor onboarding, on-call tooling, two founder reviews) — total $15-25K. With a senior LATAM or Eastern European engineer, $4-7K.
Artifact 1: the eval set
The eval set is the bridge’s foundation because it makes every other artifact testable. Without it, “the fallback works” and “the new model is as good as the old one” are unverifiable claims.
What gets installed. An evals/ directory with 20-50 input cases sliced into easy / hard / adversarial; an expected output for each (founder-written, senior-edited for testability); a scoring function — regex, JSON-schema, LLM-as-judge, or hybrid — producing per-case pass/fail and per-slice pass-rate; one command to run everything; and a CI step that fails builds when pass-rate drops by more than three points.
Claude Code accelerator: if the founder has a CLAUDE.md project memory, the senior greps it for “must”, “should never”, and “always” — every one of those lines is a candidate eval assertion. The eval set is the founder’s most valuable long-term asset. Prompts change weekly, models deprecate. The eval set survives both.
Artifact 2: the model abstraction
A Claude Code prototype usually hardcodes the model identifier in five places. The prototype works. It is also unprepared for the predictable event in which the model is deprecated, gets too expensive, or is outperformed by another frontier model.
What gets installed. A single model.py or model.ts with one generate(prompt, params) function the codebase calls; the model identifier as a .env config; exponential-backoff retries for 429 and 529 (the two failure modes that hit hardest during launches); defined timeouts; and a mocked unit test so the codebase is testable without burning tokens.
The eval set now runs against any configured model. The senior demonstrates this at handoff by running the suite against Claude Opus 4.8 and against GPT-5 and showing both pass-rates. Model substitution becomes two numbers in a terminal. Current frontier rankings (Gemini 2.5 Pro, GPT-5, Claude Opus 4.8, Claude Sonnet 4.6) are tracked on the Artificial Analysis leaderboard.
Artifact 3: the fallback path
The Anthropic API errors on a real fraction of production calls. The model occasionally returns output that fails eval scoring. Users occasionally submit inputs the prompt was not designed for. The prototype does not address any of these — it raises an exception, returns a stack trace, or returns silently incorrect output.
What gets installed. A defined hierarchy. API error or timeout: retry with backoff; if still failing, route to a secondary model via the Artifact 2 abstraction; if still failing, return a defined error response with a support contact. Output fails eval scoring: for high-stakes outputs (financial, medical, legal), queue for human review and return “we will email within 4 hours”; for lower-stakes, return with a confidence-low badge. Out-of-distribution input: detect via length, language, and schema validation; return “this input is outside what the system handles” rather than silently routing to the model.
A prototype that raises a stack trace once a week is acceptable in private beta; a shipped product that does the same is a refund and a churn.
Artifact 4: observability
Observability is the biggest hour line — usually 16 hours — because it combines vendor integration, schema design, and dashboard work. A prototype has print() statements and maybe a log file, no way to answer “what was the eval pass-rate on yesterday’s production traffic?”
What gets installed. Structured JSON logs with request ID, model identifier, prompt template version, input and output token counts, latency, error status, and user or session ID. Request tracing through a vendor — Helicone or LangSmith are the founder-stage starting points; Honeycomb and Datadog become correct at small-team scale. Token and cost metrics rolled up daily and per-user, so the founder can answer “what does each customer cost me?” without a spreadsheet. An eval-pass-rate dashboard running the suite against sampled production traffic hourly — the founder’s standing answer to “is the product still good today?”
The shape is identical to what an agency installs; see the agency observability stack we install on day one. The bridge ships the same stack at lower vendor tier.
Artifact 5: the runbook
The runbook is a single markdown file naming every failure mode and a three-step recovery for each. It exists because the founder will get a customer complaint at 9pm Friday and needs to know in two minutes whether the system is broken, the customer is wrong, or Anthropic is degraded.
What goes in. A failure-mode catalog (every error code, one line, one-sentence diagnosis). Recovery procedures (three phone-executable steps per mode — e.g. “if eval pass-rate is red and Anthropic is healthy, git revert HEAD && deploy”). Escalation paths (which incidents wake the senior, which need an Anthropic ticket, which wait for business hours). A contact list.
Six hours is enough because the senior has seen every failure mode before; the founder has not. The runbook converts the senior’s prior into the founder’s present-tense capability.
Artifact 6: the on-call schedule
The on-call schedule answers the simplest question of the six: when the system breaks at 3am and the founder is asleep, who fixes it?
What gets installed. A named on-call human — usually the senior themselves on a part-time retainer (~$2K/month buys ~5 hours of on-call attention and one weekly check-in). A paging tool (PagerDuty, BetterStack, Grafana OnCall, or a Slack-plus-Twilio webhook for the smallest envelopes). A defined SLA (99% for non-critical, 99.9% for revenue-bearing) that decides what wakes someone at 3am versus what waits until 9am. A rotation cadence with a vacation backup.
This artifact most clearly separates a prototype from a shipped product. A prototype is something a founder shows; a shipped product is something a customer pays for with the implicit promise that someone competent is watching the dashboard. See the DIY vs hire decision framework for the founder profiles where the senior-retainer model fits.
Cost and calendar arithmetic
The bridge fits in two weeks because the artifacts compose. Eval set first (tests everything downstream). Model abstraction next (makes the fallback path possible). Fallback path next. Observability runs in parallel. Runbook and on-call close out week two.
| Week | Hours | Artifacts | Cost |
|---|---|---|---|
| 1 | ~30 | Eval set, model abstraction, fallback path begun | ~$6K eng + $1K vendor |
| 2 | ~24 | Fallback completed, observability, runbook, on-call | ~$5K eng + $3-7K vendor & tooling |
| Total | ~54 | All six | $15-25K |
The range calibrates by three variables: senior geography (US/EU ~$200/hour vs. LATAM and EE ~$80-120/hour), observability vendor tier (Helicone free vs. Datadog production), and feature count. Founder time runs ~10 hours of review and eval-labeling. A full agency engagement producing the same six artifacts plus feature build runs $80-150K over 10-14 weeks; see what production-ready AI actually means. The bridge ships the same artifacts at one-fifth the price because the founder has already done the feature work.
The handoff conversation
The founder is buying six named artifacts and the confidence that the prototype is now a product, not engineering hours. Five questions the founder should ask:
- Which artifact worries you most for my codebase, and why? A senior who names one and explains a specific risk is the hire. “All routine” is a polite hire-pass.
- What does the eval set look like for a product like mine? Answer must reference the founder’s domain, not generic LLM evals.
- Which observability vendor for this budget, and why? “Whichever you prefer” is wrong.
- What is your retainer rate after the bridge? If the senior offers no continuity, the bridge ends with an on-call gap.
- Written reviews, verbal, or PR comments? Written reviews scale to founder reading speed.
Five questions the senior should ask back:
- Show me the
CLAUDE.mdand any saved prompts. If neither exists, the eval set will take longer. - Worst output this month — what did you do? Calibrates the founder’s eval intuition.
- What does a 24-hour outage cost you? Sets the SLA and on-call cadence.
- Next three roadmap features? Determines whether the model abstraction is light or heavy.
- Who else has access to this codebase? Undocumented helpers get formalized or retired.
Artifacts that change hands: a 1-page bridge summary, the runbook, eval-set documentation, a 30-minute walkthrough recording, and a credential inventory with rotation dates.
What changes for the founder after the bridge
The founder keeps the prototype, the prompts, the eval intuition, the customer relationships, and the product roadmap. The founder gives up the false belief that the system is durable without operational discipline, and the lonely 3am pager. Three day-to-day changes:
- Prompt changes go through the eval suite first — the founder still edits prompts; the suite catches regressions before customers do.
- The observability dashboard becomes the morning ritual — five minutes on the eval-pass-rate and cost-per-user graphs, which reveal problems weeks before customers complain.
- The retainer replaces the on-call relationship — the senior is reachable but mostly does not need to be reached.
For the diagnostics worth running first, see the ready-to-rebuild signal and stop vibe-coding production.
Frequently Asked Questions
What is the Claude-Code-to-shipped-product bridge in one sentence?
A two-week, $15-25K engagement in which a senior engineer installs six artifacts — eval set, model abstraction, fallback path, observability, runbook, on-call schedule — onto a Claude Code prototype, converting it into a system a paying customer can rely on.
Why these six and not more or fewer?
The minimum set where each artifact tests, contains, or recovers from a different category of failure. Drop one and a failure mode goes unhandled. Add a seventh (load balancing, A/B testing, multi-tenancy) and the work crosses into product engineering — a separate engagement.
Can the founder install the artifacts themselves?
A founder with 1-2 years of engineering experience can install three — eval set, model abstraction, runbook — over four to six weekends. Observability, fallback paths, and on-call take a senior far less time than self-teaching does. The economics favor hiring the bridge.
How do I find a senior engineer for the bridge?
Three supply pools: senior engineers at AI-native agencies taking side engagements, indie consultants who specialize in production AI work, and the senior bench at idea-to-product partners. Signals: at least one prompt-bearing system shipped to paying customers in the last 12 months, a written code-review portfolio, a defined retainer offer.
What if my prototype was built in Cursor or Lovable, not Claude Code?
The six artifacts are tool-agnostic. The Claude Code accelerators — CLAUDE.md, MCP servers, slash-command workflows — do not apply, but the bridge work is identical. Lovable prototypes occasionally need an export-to-code step first.
How does this compare to the 5-week vibe-code-then-hand-off pattern?
The 5-week pattern is the full recipe from blank repo — 2 weeks founder prototyping, 1 week senior review, 2 weeks bridge. This piece is the bridge alone, for founders who already have a working prototype.
What if my prototype uses MCP servers?
MCP-based prototypes save about three hours on the bridge because integration boundaries are already explicit. The senior treats each MCP server as a named dependency with its own runbook entry and retry logic.
What does the bridge not include?
New features, UI redesign, marketing site, billing, multi-region deployment, SOC 2 prep, or a full-time hire. Anything beyond the six artifacts is a separate engagement.
Right next step if I have a Claude Code prototype today?
Run the ready-to-rebuild self-check; write a 1-page brief naming your current model, worst output, and top-three production worries; get fixed quotes from two senior engineers using that brief. About a week.
Closing
A Claude Code prototype is genuinely valuable in 2026 — a non-engineer founder can ship something that works in a weekend. What does not collapse, and what the public web of vibe-coding boosterism elides, is the operational gap between a system that runs and a system a paying customer can rely on. That gap is six artifacts wide and roughly two weeks tall. The bridge is the cheapest path across that does not dispossess the founder of their product.
Next step: the AI MVP Scoping Worksheet — a one-page document that turns the bridge into a vendor brief two senior engineers can quote against in the same week.
Dirk Jan van Veen, PhD
