A prototype needs to answer a question
A prototype verifies a bounded hypothesis, such as whether a journey is understandable or a task can be performed with the available data. It should make explicit what is simulated and what actually works. A successful demonstration confirms only the conditions that were observed during that particular experiment with the application.
Imagine an equipment hire company wanting to accept booking requests online. The first prototype could use a fictional catalogue to check whether someone finds the equipment and understands how to enter dates. At this stage, a useful result might be learning where the request becomes confusing for the person making it.
You do not need to build the entire operation to answer that question. You can present a simulated confirmation as long as nobody mistakes it for an actual booking. The boundary is part of the test: participants should know that equipment is not reserved and that the journey is still being explored.
A dependency can also be simulated to study presentation, but that leaves the real connection unverified. Showing availability in a calendar does not demonstrate synchronisation with inventory. When the question becomes about that integration, you will need to observe the data source's actual response under the conditions that matter.
The work of planning an application before coding helps choose the question for this stage. A prototype with a clear objective can be small and useful. Without knowing what you want to learn, you risk evaluating progress solely by the number of screens you can already show to someone.
To prepare your next step, explore Building digital products with AI.
An internal tool starts supporting real work
Once the team depends on the application, define who maintains it, how failures are detected and how work continues if it stops. Internal use may reduce some presentation needs, but it does not remove requirements around data, access and recovery. The consequence of failure determines how much care the tool needs.
In the hypothetical company, the tool might start organising requests received by the sales team. If a booking disappears, someone could promise the same equipment to two people. That impact exists even when no customer directly accesses the system and all its users know one another inside the business.
Define which data the team considers valid and where it checks uncertainty. If inventory is still updated manually, that condition needs to be visible in the process. A person should not interpret an outdated number as guaranteed availability simply because it appears in a dashboard that looks polished and convincing.
You also need someone responsible for following up on problems. A tool used daily cannot depend only on whoever remembers to open the conversation where it was built. Record its essential operation, how to report failures and the alternative way of working during an interruption, where such an alternative exists.
Before making use routine, apply the discipline of testing an automation before handing it over to the team. Observe real tasks, including relevant changes and cancellations. The team should distinguish what has been verified from what remains an experiment limited to particular cases and conditions within the wider process.
A customer product needs a clear promise
When customers receive the application, its behaviour becomes part of the service being offered or purchased. Explain what the person can do, when an action is complete and where to seek help. The journey must be understandable to someone who was not involved in construction and does not know its limitations.
In equipment hire, submitting a request and confirming a booking are different actions. If availability requires a team review, the product should say it received a pending request. Displaying a confirmed booking message would create an expectation that the operation is not yet prepared to fulfil at that point.
The same care applies to subsequent follow-up. People need to know where to check the response, how to communicate a change and what happens if the application interrupts the journey. Those decisions are part of the product even if they did not appear in the first demonstration that inspired its launch.
Think about service continuity as well. Who receives a problem, identifies affected requests and informs anyone needing a response? You do not have to promise absolute availability to offer a responsible product, but you do need to define the support you can provide and organise operations around that promise.
Data and permissions need attention at every stage
The labels prototype and internal tool do not make data less sensitive or actions less real. If an application receives customer information or changes a process, its boundaries must reflect that use. A demonstration should use appropriate information, and access should correspond to the responsibilities of each person using the system.
A demonstration account can help present a product without exposing real requests. However, hiding an option on screen does not replace access checks in the system delivering the data. Authorisation must apply to requests and resources, including when someone attempts to reach them through a different route within the application.
In the hire example, a customer should consult their own requests, while the team should have the access needed to handle them. That requires checking both the permitted journey and an attempt to consult another person's request. Being signed in does not automatically grant access to every piece of information.
An internal tool controlling expensive equipment may warrant more care than a small public product without consequential actions. Do not treat the three categories as an automatic security scale. Evaluate the information involved, the effect of each action and how difficult it would be to repair an error after it happens.
Decide when to advance using evidence
An application is ready for a new use when the journeys, boundaries and operation required for that use have been checked. Define those criteria before inviting more people to depend on it. Visual polish and a flawless demonstration help present the work, but they do not replace an assessment of readiness.
To move from an experimental catalogue to the team's tool, confirm the source of availability, request recording and the response to changes. To open the journey to customers, add clarity of the promise, separation of access and how questions will be handled. Each transition has its own decisions to demonstrate.
This is a useful criterion for integrating AI into business processes: usefulness depends on the work still making sense beyond the demonstration. The application can begin with limited use, defined people and explicit conditions while you gather enough evidence to decide whether a broader use is appropriate for the business.
Record what was tested, with which data and under which conditions, alongside what remains unconfirmed. That information lets you choose the next stage without presenting intention as completion. Progress is tied to the commitment you can actually fulfil towards the people who will use the application next in their work.