From Prototype to Production

The prototype proved the idea; now it has to survive the real world. Moving from prototype to production is not "keep the same code and hope." It's a deliberate change in bar: reliability, security, data, and trust — the production dimension you first met in Tutorial 1. This tutorial covers when you're actually ready to make the shift, the seams where a prototype should stay a prototype, and how to turn your working demo into software that behaves the way real users deserve.

Table of Contents

• When You're Ready to Cross Over
• The Definition of Done
• Keep Prototype and Production Separate
• The Prototype-to-Production Gap: What Breaks
• Mock Data to Real Data, Cleanly
• Add the Minimum Security Floor
• Make Failure Honest and Observable
• A Production-Lite Example
• Don't Let the Prototype Go-Live by Itself
• The Production Mindset, Not Just Production Details

When You're Ready to Cross

The crossing happens when a hypothesis has become an adoption. Signs you're ready to invest in production (and not a week too early):

• Real users get real value from the prototype — not "useful in the demo," but "they used it twice this week."
• The core loop is proven and the important failure modes are known.
• You can name who depends on it and what breaks if it dies at 3am.
• The data is (or is about to become) real and sensitive.

The brutally honest test from Tutorial 1 still holds: "If this broke tomorrow, would a real user be harmed or lose trust?" The day that answer becomes yes, the prototype has grown into production — whether you named it yet or not.

The Definition of Done

Before you start hardening, write the "What must be true" statement for production — the list that ends your era of the throwaway and begins the era of the depended-on:

• A failure surfaces loudly, not silently — the team sees it.
• Every value the user can change is checked at the boundary.
• Real credentials and sources are handled like secrets; nobody's data crosses the wrong boundary.
• The critical path is repeatable (a re-run does not double-charge or double-send).
• You can trace what happened: an audit of runs, state, and errors.

That list is your definition of production-ready. Anything not on it is a candidate to stay prototype-thin.

Keep Prototype and Production Separate

The single most common error: copying the prototype folder and calling it the product. The prototype proves an idea; production must own its absence of failure forever — different goals, different bars. Do not let the prototype's "the stakes are low" nature leak into the world where stakes are real:

• Start production as a clean, deliberate project — not the demo, enhanced.
• Preserve the learning and the plan from the prototype (the change-log from Tutorial 7 becomes the roadmap), but not its fragility.
• Hold production code to a revisit bar when it touches real data, credentials, or money.

The prototype was a question; production is the reliable answer. Different jobs, different standards.

The Prototype-to-Production Gap: What Breaks

Most of the gap is covered by the tutorials you already passed. Expect the shift from "nice demo" to "real system" to show up across these:

Cross them one at a time, not all at once. The moment you hook real money, real customer lists, or real health data into a thing — that's when each of these stops being optional.

Mock Data to Real Data, Cleanly

The swap from mock to real is easy only if you kept the seam (Tutorial 6). If screens talk through access layer fetch_accounts(), replacing mock with the real API is one change, not a refactor. The hard part: expectation.

• Real data is messy: missing, duplicated, oddly-cased; your validation must not assume it's clean.
• Real data has volume and speed: enforce timeouts; never block a request on a slow call.
• Real data must stay guarded: once unauthenticated data leaves the prototype, it stops being mock.

Pace it so a throwaway idea doesn't outlast its welcome: keep the mock seam until you're about to genuinely depend, then swap, and smoke-test the real path the moment you do (Tutorial 7).

Add the Minimum Security Floor

Production begins with security. The floor, before anything with real data goes live: the thing lives behind some login and each caller carries an identity. Then the dangerous cases become the literally important cases:

• Who can call this (Authorization, scopes, least-privilege roles)?
• What can a caller do that absolutely must be blocked (e.g. DELETE guarded, money-path refuses anomalies like negative amounts)?
• When a request fails, failing safe beats failing open — the default state for unsafe: refusal (fail closed).

Note: security is not a new vision; it's removing the demo-goggles. Don't bolt it on at the very edge; the floor is mostly default-deny so that an "oops" can't become a breach.

Make Failure Honest and Observable

In prototype mode, "it just showed an error" was acceptable. In production it is the entire conversation. Two behaviors carry production:

• Fail loudly, not quietly. A hard failure, a clear message, and a stale-run guard beats a generic "something happened" that masquerades as success.
• Observability is a feature. A log line per critical action; an alert when a real run fails; a dashboard view so an operator sees problems without digging.

Production software that hides its own illness cannot be cared for. The cheap prize: even small additions — an "alerts" endpoint, a health check, a run record — turn a silent box into a machine you can trust and repair.

A Production-Lite Example

Here is the same prototype from Tutorial 2, hardened just enough that a real user depending on it is safe. Notice what changed: inputs are checked at the boundary, a re-run cannot double-process, and success is explicit.

# production-lite: same shape, but failure is loud, inputs checked,
# and a re-run is repeatable.
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

processed = set()   # idempotency guard: a retried key can't double-charge

@app.post("/pay")
def pay(invoice_id: int, amount: float, idem_key: str):
    if amount <= 0:
        raise HTTPException(status_code=400, detail="amount must be > 0")
    if idem_key in processed:
        raise HTTPException(status_code=409, detail="already processed")
    # charge through the real provider here, then:
    processed.add(idem_key)
    return {"invoice_id": invoice_id, "charged": amount}

Explanation: the failure modes you'd forgive in a demo — a negative payment, the same request arriving twice — are now checked at the boundary and refused as errors. Refusing a bad amount and refusing a duplicate each protect a real user's money and trust. That is the production floor you add precisely because people depend on it. (In a real build, processed is a durable store shared across instances, not process memory — but the pattern is exactly this.)

Don't Let the Prototype Go-Live by Itself

A real risk in the handover: the prototype was already live — someone connected real data, real users logged in, and it kept running on a laptop under the desk. It functions, so it must be production, right? That's the trap.

The go-live needs intent, not accident. Before you call the prototype "shipped," make sure the thing a real person depends on is something you'd defend at 3am: a place you can restart it, an alert if it dies, the real data source, the guarded credentials. If it ran by itself and you only discovered it later, that's adoption, not a plan — and it's the most dangerous way to go production: with no safety rails and no owner.

If you can't defend the running thing yet, take it back to prototype mode and formally make the crossing — deliberately, with a done-list — instead of letting an orphaned copy bumble on as the product.

The Production Mindset, Not Just Production Details

Hardening has a shape, but keeping it is a mindset. The full production building plan is the subject of a deeper series; what you carry forward from here is the habit behind every detail:

• The bar is who depends on it, not who built it. A fluke demo becomes real at the moment a real user leans on it.
• Reliability is earned by default-deny. State the unsafe case, and refuse it until proven safe — in code and in habit.
• Observability is the floor of ownership. What you cannot see failing, you cannot fix — so you watch the thing you ship.
• The loop never ends. Prototyping taught you to test with real users and iterate; production just changes what "right" means — and keeps rewarding the same honest feedback loop.