Contents
A prototype provides evidence about particular questions under particular conditions. Moving it into production starts by identifying those conditions and deciding which conclusions still hold for real use. Preserve the learning, then assess the implementation against the service you now intend to provide.
Record what the prototype actually demonstrated
List the questions the prototype explored and the evidence collected. Was it a user-interface exercise, an integration experiment or a model running on a limited dataset? Describe who tried it, what they could do and what was outside the exercise.
Identify simulated elements and manual assistance. A demonstration may rely on prepared records, a person correcting outputs or a connection that behaves differently from the live service. These choices can be appropriate for learning, but they need to be visible before the next team estimates production work.
Define the first production context
Name the intended users, the tasks they will complete and the information they will provide. Describe how they begin, get help, correct mistakes and leave the service. Decide which limitations are acceptable for the first release and how users will understand them.
Turn the demonstrated journey into explicit acceptance criteria. Include permissions, failure states and administrative work. If the product will connect to other systems, confirm their actual interfaces and owners rather than assuming the prototype's connection establishes every requirement.
Decide what to retain based on evidence
Review the prototype's code, dependencies, data handling and deployment approach. Ask whether each part can support the intended release and be maintained by the receiving team. Keep the reasons for retaining, changing or replacing a component attached to that decision.
Avoid assuming that every prototype must be discarded or that a working demonstration should be preserved unchanged. Compare the effort of understanding and adapting the existing implementation with the effort of rebuilding the required behaviour. Include verification and operational knowledge in both options.
Plan the engineering work around real use
Identify the checks needed for the core journey and its important boundaries. Verify who may perform each action, how data changes are accepted and how failures are communicated. Establish a repeatable build and release process so the product is not dependent on one person's development environment.
Exercise the application under conditions relevant to the first users, including their devices and accessibility needs. Investigate assumptions about external services and expected usage. Describe any limits discovered and the choices available rather than treating a successful local run as general readiness evidence.
Give operation an owner before launch
Agree who monitors the service, responds to problems and maintains its dependencies. Identify the information needed to diagnose failures without exposing sensitive data. Document configuration and routine tasks in the place the operating team will use.
Plan recovery and data handling alongside deployment. If there is existing trial data, decide whether it should migrate, be retained separately or be removed through an authorised process. Make those decisions explicit and verify the result in an appropriate environment before the public cutover.
Review the release against its own acceptance criteria
Demonstrate the completed production journey to the people responsible for acceptance. Keep user approval, automated verification and operational readiness evidence distinct. Record unresolved limitations and decide whether they are acceptable for the intended release.
After launch, compare actual use and support effort with the assumptions made during the transition. Feed that evidence into the roadmap. The prototype's value is the learning it made possible; the production product needs its own continuing cycle of evidence and decisions.
Turn a prototype booking into a supported transaction
Suppose a fictional prototype stores appointments in a developer’s local file and returns “booked” when a button is pressed. It was sufficient to demonstrate an interaction. Production requires a different acceptance boundary: the backend validates the user and slot, records one accepted booking and returns its reference. The interface must represent failure or an unresolved response honestly.
Inventory each shortcut and its replacement evidence. Local storage becomes a controlled data store with backup and restoration; a hard-coded user becomes enforced identity and organisation access; a synchronous email call becomes a documented delivery state; manual deployment becomes a repeatable release with recovery. Preserve the useful interaction design, but do not infer any of those controls from the prototype’s appearance.
Exercise the difficult sequence: the booking is accepted, the response is lost and the user tries again. Verify one booking and an understandable confirmation, then test a forbidden organisation and an unavailable destination. Estimate the resulting engineering work against this inventory. This is conversion of an implementation, distinct from choosing an initial experiment or deciding whether an already engineered MVP meets a pilot release gate.
How this relates to Veda Software’s work
Encounter demonstrates customer navigation supported by managed trip information. It is relevant to the surrounding product responsibility, but the published case makes no claim about the prototype shortcuts in this example.