The moment a prototype begins carrying real expectations, its proof, ownership, and possible ending need to change.
A prototype is allowed to answer a narrow question. Can this interaction make sense? Can these systems exchange the necessary information? Can an operator see enough evidence to make the next decision? Those are useful questions, and answering one doesn't make the result production-ready.
Trouble begins when a useful demonstration accumulates social weight. Someone relies on it twice. Its address gets shared. A pilot becomes part of a weekly routine. The software hasn't crossed a technical finish line, but the consequences of its absence have changed. That's usually how the transition arrives: sideways, without a ceremony.
I use explicit readiness states to make that transition discussable. “Promising,” “pilot,” and “production” can't be compliments. Each state says what's been proved, what remains bounded, and what obligation now exists.
Experiment: protect the question
During experiment work, discipline means keeping the question small enough to answer honestly. A static artifact can prove layout and narrative flow. A scripted interaction can prove a sequence. A thin live connection can prove that two boundaries fit. I don't stretch any of those demonstrations into a claim about reliability under ordinary use.
The proof boundary belongs beside the artifact. I state which parts are live, which are representative, what data conditions were exercised, and which failure behavior remains unexplored. This keeps me from dismissing useful learning because it isn't production software or treating one convincing path as evidence for everything around it.
Ownership at this stage can remain close to the builder. Breakage is acceptable if the audience understands the terms and no routine depends on immediate recovery. Even here, the experiment needs a named question and a decision date. Otherwise it becomes permanent ambiguity with a friendly interface. I've built enough of those to recognize the species.
The threshold for leaving this state is evidence, not enthusiasm. The prototype has to answer its intended question well enough that the next investment can be justified. If it can't, stopping is a successful experimental outcome.
Adoption: follow the dependency
Adoption starts when people incorporate the prototype into real work or make plans that assume it'll be available. The signal I watch is dependency, not traffic. A tool used by a small group can still carry a consequential decision. A tool opened frequently may still be a disposable convenience.
At this threshold I ask what happens when the prototype is wrong, stale, or absent. Who notices? Can work continue elsewhere? Which record remains authoritative? Who owns access and correction? The answers tell me how much production discipline the reliance has earned.
This doesn't mean every adopted prototype needs the full machinery of a mature platform. It does mean the proof has to widen. Representative data is replaced or supplemented by defined live sources. Failure states become visible. Routine support has an owner. Changes are reviewed against the workflow now depending on them. Readiness stays specific: ready for this audience, this workload, and these consequences.
I also look at reversibility. Early users need to know whether they can return to the prior workflow and what'll happen to work created in the pilot. If adoption changes a durable record or teaches people to stop maintaining an older path, the transition is already larger than an interface trial. I account for that cost before convenience hardens into dependency.
The decision can still be “continue the pilot.” That's legitimate when the boundary remains clear. What I avoid is a blanket production label used to settle discomfort. Production readiness isn't one property that switches on. Security, recoverability, operability, data quality, and support may mature at different rates, and the adoption decision should name the gaps that matter now.
This threshold also changes design priorities. During experiment work, speed of learning dominates. During adoption, I spend more attention on hidden dependency. A manual step may remain perfectly reasonable if it has an owner and visible cadence. An elegant automation may be premature if nobody can explain how it fails.
Retirement: decide before neglect decides
Every prototype needs an ending path before it becomes inconvenient to discuss. Retirement might follow a failed experiment, a better replacement, or a decision that the demonstrated value doesn't justify continued ownership. It can also be the right response when a pilot succeeds at teaching but shouldn't become the implementation that carries the lesson forward.
Retirement discipline begins with identifying what must survive. A decision record may matter even when the code does not. Data created during the pilot may need export, disposition, or a clear statement that it was temporary. Shared links and routines need to stop pointing at an artifact that no longer has an owner.
I look for the same dependency signals used at adoption. Who has incorporated this into work? What expectation has to be reset? Which source holds the durable record after shutdown? The answers tell me whether retirement is simply removing an experiment or coordinating a service change.
An explicit retirement threshold keeps a prototype from being maintained by embarrassment. It's easier to say “one more month” than to admit that the question has been answered and the artifact has no durable home. That extension quietly creates support work without improving readiness.
The next decision stays bounded: continue the experiment to answer a named uncertainty, adopt the pilot for a named use with named ownership, or retire it while preserving the material that deserves to outlive it. A persuasive demo may start the conversation. Before it becomes part of Tuesday morning, I decide who owns it and how we'd stop.