Prototype vs Production Framework

The Problem

Your prototype works. Now someone asks: "Can we ship this?" And you freeze.

The code is held together with hope and TODO comments. Shipping feels irresponsible. But rewriting from scratch feels wasteful. You're not sure how to evaluate what you have.

The real question isn't "prototype or production." It's: What parts of this prototype can survive contact with production?

The Core Insight

Not all code needs the same treatment. A prototype has three types of code:

The framework helps you categorize each piece of code and make deliberate decisions.

The loop that does this

Run the triage below by hand the first time, on a project you actually care about. Not because the manual pass is better — it isn't — but because the scoring has two places it quietly goes wrong, and if you have never watched those places yourself you will take a confident green verdict at face value.

After that it should be one instruction, not an afternoon: "Go through my project piece by piece. For each, tell me what breaks if it fails, how solid the code is, and whether it's keep, harden, or rewrite — with a file and line behind every call." Save it where your agent will find it again — a skill if yours installs them, otherwise the instructions file it reads each session. A verdict with no line number behind it is a guess. The two calls that stay yours: how much a failure would really cost you, and whether you can live with the risk you're choosing to keep.

The Decision Framework

Step 1: Risk Assessment

For each component, ask: What happens if this breaks in production?

High-risk code needs hardening or rewrite. Low-risk code might ship as-is.

Step 2: Code Quality Audit

For each component, evaluate:

Step 3: The Decision Matrix

Combine risk level with quality score:

                    Low Quality    Medium Quality    High Quality
High Risk           REWRITE        HARDEN           KEEP (review)
Medium Risk         HARDEN         HARDEN/KEEP      KEEP
Low Risk            KEEP (maybe)   KEEP             KEEP

Applying the Framework

Example: E-commerce Checkout Prototype

Let's categorize a prototype checkout flow:

Hardening Checklist

When a component needs hardening (not rewrite), here's what to add:

Minimum Viable Production (MVP)

Startups have a name for the smallest version that can prove an idea: it's called a minimum viable product - and in the shorthand everyone actually uses, it's the MVP. Hardening has the same floor:

1. Input validation - Validate types, ranges, required fields
2. Error handling - Try/catch with meaningful error messages
3. Null checks - Handle missing data gracefully
4. One test - At least one test for the critical path
5. Logging - Log errors with enough context to debug

Full Production

Add to MVP:

1. Edge case tests - Empty arrays, null values, boundary conditions
2. Documentation - Function signatures, expected behavior
3. Metrics - Track usage, errors, performance
4. Rate limiting - Prevent abuse (if applicable)
5. Graceful degradation - Fallbacks when dependencies fail

Rewrite Triggers

When should you rewrite instead of harden?

The Sunk Cost Trap

"But I spent 3 hours on this!"

Doesn't matter. Those hours are gone whether you keep the code or not, and letting them steer the decision has a name: sunk cost. The question is: Will hardening this take more or less time than rewriting?

Rule of thumb: If hardening a component would take more than 2x the time to rewrite it properly, rewrite.

Technical Debt Assessment

Every shortcut you took to get the prototype working is a cost you deferred, not one you dodged - engineers call this technical debt. Every prototype accumulates it; categorize it:

Reckless debt is the killer. If you shipped code without understanding it, you're going to pay interest forever.

Failure Patterns

1. The Perfectionist Trap

Symptom: Nothing ever ships because nothing is "production ready."

Fix: Define "good enough" before you start hardening. Hit that bar and ship.

2. The Ship-and-Pray

Symptom: Everything ships as prototype. Production is constant firefighting.

Fix: Use the risk matrix. At minimum, harden high-risk components.

3. The Rewrite Addiction

Symptom: "This would be better if we just started over" - said repeatedly.

Fix: Rewrites must be justified. If you can't quantify why hardening won't work, don't rewrite.