An AI prototype is ready to rebuild when seven specific markers trip — not when the code feels bad, not when an engineer tells you it should, and not at a round-numbered milestone like “100 users” or “10K MRR”. The markers are objective, observable, and weighted toward business signals rather than engineering aesthetics. A prototype tripping one still needs patching. A prototype tripping four is a system whose cost of continuing to patch has already exceeded the cost of stopping to rebuild.
This article names the seven markers and tells you what to do when you spot each. It is written for the founder who shipped the prototype themselves with Cursor, Claude Code, Lovable, v0, or Replit Agent, and is now deciding whether to keep patching, hire a fractional engineer, or hand the rebuild to a partner.
Why this matters: rebuild is a business decision, not an engineering one
Most prototype-to-production content reads like an engineering checklist — acquire an eval set, instrument observability, add fallbacks. The checklist is correct, but it answers the wrong question. The founder is not asking “what does production AI need?” They are asking “should I stop the bleed of patches and spend a quarter rebuilding?”
That second question is a business decision. It depends on revenue exposure, operational cost, founder capacity, and the proven shape of the product. A prototype lacking an eval set is fine with three free users. The same prototype with a paying $50K-ARR customer is a liability.
This decision sits within the DIY-with-AI manifesto and the broader idea-to-product manifesto. It pairs with the vibe-code then hand-off pattern and with why most DIY AI MVPs ship a demo, not a product. Missing the rebuild signal early is one named root cause in the anatomy of a runaway AI project.
Read the seven markers as a panel — any one is information, four is a verdict.
Marker 1: a paying customer is attached
What it looks like. A user is paying you money — recurring or one-time — and the prototype is what they paid for. Until this marker trips, every breakage is a free user’s inconvenience. After it trips, every breakage is a refund risk, a churn event, or a public complaint. The threshold is the first paying customer, not the tenth.
What to do. Inventory the failure modes the prototype ships with. If you cannot answer “what happens when the model returns garbage”, “what happens when the API rate-limits”, and “what happens on an input I never tested”, you are running an uninsured business. The rebuild’s first deliverable is closing those three gaps.
What changes if you ignore it. Refund processing eats founder hours. A single churned customer in a small-cohort MVP often costs more in time-to-replace than the rebuild would have cost in dollars. The signal is not “rebuild today” — it is “the cost of not rebuilding has stopped being zero.”
Marker 2: an eval set exists but you cannot maintain it
What it looks like. Somewhere in the repo is a file called evals.yaml. Maybe Claude Code scaffolded it. It has twenty rows and has not been updated in six weeks. You do not run it before deploys, because last time you tried, two cases failed and you could not interpret the diff.
This is worse than no eval set, because it produces the illusion of a quality gate. A reviewer sees evals.yaml in the tree and assumes the system is checked. The founder has not run it in two months. Quality is invisible.
What to do. Either operationalize the eval set — wire it into CI, hand-grade failures, expand to forty cases — or remove it. The rebuild makes the eval set first-class: run on every deploy, fail the build on regression, owned by a named person.
What changes if you ignore it. Quality drift is silent. The model correct on twenty cases at launch is correct on fourteen six months later, because the input distribution moved and you never caught it. Customers churn before the founder knows the system regressed.
Marker 3: on-call cost exceeds founder hours
What it looks like. Add up the founder’s last four weeks of unscheduled time on the prototype: customer complaints, “is this broken” Slack messages, manual retries of failed jobs, hand-rolled fixes for one customer’s edge case. Compare it to planned-feature time. If on-call has eaten more than 40% of the hours that were supposed to go to building, this marker has tripped.
At 40%, founder velocity is negative — they are no longer shipping forward, only paying maintenance taxes.
What to do. Track on-call hours for one more week in a spreadsheet to confirm the ratio. If confirmed, the rebuild is the only intervention that recovers founder time. Hiring a contractor for on-call on top of a fragile prototype extends the bleed at a higher hourly rate.
What changes if you ignore it. Founder burnout is the slowest cost in an MVP. The on-call hours are not free — they are the cost of every roadmap item that is not happening.
Marker 4: you have stopped iterating because change scares you
What it looks like. You have had a feature idea for two weeks. You have not built it. The reason is not that you do not know how — the last three small changes broke production in surprising ways, and you have learned that touching the system is risky.
This is the most diagnostic marker because it is psychological, not technical, and it shows up before any engineer would name it. The founder has internalized that the prototype is fragile in ways they cannot predict. The belief is correct, and the response — stop iterating — is rational. The cost is that the product has stopped evolving.
What to do. Write down the last three changes that scared you and what they broke. The rebuild’s deliverable is to restore the founder’s confidence that the system can be changed safely — through tests, evals, type contracts, and observability.
What changes if you ignore it. Stagnation. Competitors who started later but rebuilt earlier ship features you cannot match. The product becomes a snapshot of the founder’s idea at launch, diverging from the market.
Marker 5: one capability is provably worth scaling
What it looks like. The prototype ships three or four capabilities. Six months in, usage data shows one generates most of the value. Churn concentrates among users who do not use it. Sales conversations land on that one capability. The others are nice-to-haves without data to justify them.
The signal is asymmetric value, not feature count. The rebuild is the moment to commit to the proven capability at production grade and defer the others.
What to do. Identify the capability with a measurable usage and retention signal. Cut the rebuild scope to that capability plus the minimum supporting surface. The rebuild’s economy comes from narrowing — you are buying production quality for one feature, not three.
What changes if you ignore it. Rebuild scope balloons. The engagement that should have cost $80K costs $150K because the rebuild faithfully copied a too-wide prototype. Team attention is diluted across surfaces the market has already told you it does not want.
Marker 6: a frontier model upgrade broke production
What it looks like. A provider — OpenAI, Anthropic, or Google — released a new model. You upgraded, or it happened automatically because you pinned to a moving alias. The prototype’s outputs changed in ways your users noticed before you did. Maybe the new model is verbose where the old one was terse, or refuses inputs the old model accepted.
In 2026 this happens several times a year. GPT-5, Claude Opus 4.8, and Gemini 2.5 all ship refresh cycles measured in months. The signal is not the regression itself — it is the discovery that you had no test to catch it.
What to do. Pin model versions explicitly. Build an eval set the next release runs through before you upgrade. Treat model versions as a contract surface — versioned, tested, changed deliberately.
What changes if you ignore it. The next release breaks production again, more loudly. Customers attribute the regression to your product, not the model swap, because they have no visibility into the dependency.
Marker 7: integrations need to talk to more than two systems
What it looks like. The prototype started as model + database + frontend. Now it also writes to a CRM, reads from a billing system, syncs a Slack notification, and pulls a calendar. Each integration was added in a one-line API call. None share a common error-handling pattern. When one breaks, you find out from a customer.
The two-system threshold is not arbitrary. Below it, the prototype is a single application with a database. At or above it, the prototype is a distributed system without the infrastructure distributed systems need — message contracts, retry policies, dead-letter queues, cross-boundary observability. Most DIY tools do not scaffold any of that.
What to do. Inventory the external systems the prototype touches. If the count is three or more, the rebuild’s deliverable is a typed integration layer with explicit contracts, per-call retry, and a single observability surface spanning them. Adding a fourth integration to the existing duct tape is a category mistake.
What changes if you ignore it. Integration failures compound. Customer-visible breakage shifts from “the AI got the answer wrong” to “the AI got the answer right but the CRM did not update” — harder to debug, faster to erode trust.
How to read multiple markers together
One marker is information. Two say “you have a tactical problem worth a sprint.” Four or more say “you have a structural problem the prototype cannot solve from inside its current architecture.”
| Markers tripped | Interpretation | Action |
|---|---|---|
| 1 | Healthy growth signal | Patch and instrument |
| 2 | Pressure building | One sprint to address both |
| 3 | Approaching the line | Decide rebuild scope this quarter |
| 4 | Past the line | Start rebuild planning now |
| 5+ | Compounding cost | Rebuild is overdue; every week is debt |
Composition matters as much as count. Two markers from the same category (on-call cost plus integration count) differ from two markers across categories (paying customer plus stopped iterating). Cross-category combinations are highest-urgency, because a single fix will not address both.
The cleanest rebuilds come from founders who name three markers in a sentence — “I have a paying customer, I stopped iterating, and the last model upgrade broke production” — and treat it as a procurement spec.
Next step: the AI MVP Scoping Worksheet
If you counted three or more markers, convert them into a rebuild scope. The AI MVP Scoping Worksheet — a six-page PDF — walks through which markers are tripped, which capabilities survive the rebuild, and what the engagement looks like in weeks and dollars. Request it from the main idea-to-product manifesto. Bring it into a discovery call so the conversation starts on a shared scope, not a sales pitch.
Frequently asked questions
How many markers should trip before I rebuild?
Three is the decision threshold; four is the action threshold. At three, plan rebuild scope this quarter. At four, start the engagement. Single markers can be addressed in-place. Prototypes rarely trip every marker before they fail; most fail at four or five with the rest still latent.
Can I rebuild the prototype myself with Claude Code or Cursor?
Sometimes. The deciding factor is which markers are tripped. If your tripped markers are eval set and observability, a focused weekend with Claude Code and Promptfoo can close them. If your tripped markers are on-call cost and integration count, the work is operational and architectural — DIY tools are not the right shape. The vibe-code then hand-off pattern explains where the line sits.
Is “the founder stopped iterating” really a marker, or is it just procrastination?
It is a marker when the founder can name the last three changes that scared them and what each broke. It is procrastination when no specific incident is named. Concrete fear is a fragility signal; abstract fear is a different problem.
What if my prototype only has free users — should I still watch the markers?
Yes, but the urgency is lower. Marker 1 is load-bearing. Without it, the cost of a breakage is reputation, not revenue. Free-user prototypes can afford three or four markers before rebuilding.
How long does a prototype-to-production rebuild take?
Six to twelve weeks for a single-capability rebuild scoped from a tripped-marker analysis. Variation is driven by integration count (marker 7) and whether the founder has a usable eval set going in (marker 2). See the AI MVP economics playbook for the cost breakdown.
Should I rebuild the whole prototype or only the part that broke?
Only the part one of the seven markers names. Rebuilding the whole prototype is the most common scope mistake. Marker 5 is the explicit instruction to narrow scope.
Can I delay the rebuild by hiring an on-call engineer?
For a quarter, maybe. For longer, no. An on-call engineer patching a fragile system spends most hours on incidents the rebuild would have prevented. The monthly cost often exceeds the rebuild’s amortized cost within two quarters — and the founder ends with no production system. Treat on-call as a bridge.
What’s the difference between this list and a “production readiness checklist”?
A readiness checklist names engineering attributes a production system needs. This list names the signals that say it is time to acquire them. Founders need both; the first is already well-covered by engineering blogs and provider docs.
Does this apply to AI agents, not just single-prompt apps?
It applies more strictly. Multi-step agents trip markers 3, 6, and 7 earlier than single-prompt apps because each step is a new failure surface. A founder running an agent should re-read the markers monthly.
Which marker is the most expensive to ignore?
Marker 3 is usually the most expensive in dollars because it burns founder time directly. Marker 4 is most expensive strategically; Marker 1 is most expensive reputationally. For most seed-stage founders, the answer is founder hours.
Arthur Wandzel
