The prototype looks polished. Stakeholders can click through it and the team can see the idea. Launching - or sending paid traffic to it - feels like the natural next move.
That speed is valuable. It is also the moment to change the question. The demo has shown that the idea can be presented. Before customers depend on it, the business needs evidence that they can understand it, trust it, complete the important action and receive a reliable outcome.
Answer in 60 seconds
Use these seven readiness tests before you launch or increase acquisition spend:
- A new visitor understands the offer and the next step.
- The experience carries your company’s trust signals and visual rules consistently.
- The most important customer journey works from beginning to confirmed outcome.
- Mobile and accessibility have been checked with people and devices, not only previews or automated scores.
- Real-world speed, failure states and integrations are acceptable.
- The business can measure meaningful outcomes, not only visits and clicks.
- A named person owns changes, incidents, customer response and recovery.
These tests support a decision; as IZZY practice guidance, they do not guarantee conversion, compliance or overall product quality.
1. The prototype has done its job. Now ask a different question
Today’s tools can produce something convincing quickly. Figma documents that Make can create functional prototypes and web apps through chat. Canva reports that its Code product can create interactive websites, apps and experiences. Those capabilities do not establish that a particular result is ready for customers.
A realistic prototype is not a failed product. It is a successful way to make an idea tangible, collect reactions and decide what deserves further investment. GOV.UK’s guidance on making prototypes makes the distinction clearly: realistic code prototypes can support user research, while prototype code may not meet production security or high-traffic performance needs and should not simply be copied into production. That is transferable guidance, not a universal launch method.
The question is now broader than “Does the screen work in the demo?” It is “Can we depend on the experience when the user is unfamiliar, the phone is small or something goes wrong?”
You do not answer that by adding more polish. You answer it by gathering evidence along one real customer path.
2. Can a customer understand and trust it?
For this readiness review, treat comprehension and trust as prerequisites: someone outside the project should understand the offer, proof and next step without a tour. Our guide to diagnosing visitors who do not become enquiries covers that path through contact and follow-up. Fix it first rather than treating AI-prototype readiness as a substitute.
Then inspect the generated experience beyond its ideal screen. As IZZY practice guidance, map the empty, loading, partial, error, success and returning-user states. Each should follow the same rules, explain what is happening and give a sensible next action. One polished screen does not show whether the experience is coherent.
Then check consistency. In ordinary terms, a design system means colours, type, buttons, form behaviour and language follow recognisable rules. A button should not change meaning between pages, and checkout should not feel like another company.
Figma says a Make kit can carry shared product styles and guidance into generated work, and recommends checking where output departs from those rules. That helps; it does not create an automatic match. Compare each state with the product rules the business approved.
3. Can the important journey survive real use?
Choose one journey that matters commercially: an enquiry, booking, checkout, onboarding or account change. Connect its states from entry to confirmed outcome, including when the customer leaves and returns. The decision concerns the journey, not the screen that made the demo look finished.
Treat the preview as one environment, not the result. Repeat the journey on expected devices and browsers. Open the keyboard, rotate the screen, switch away, return and slow the connection. Check whether controls remain visible, progress survives and the next action makes sense.
Draw a boundary around each outside service: payment, booking, sign-in, CRM or email. Decide what both sides see when it is slow, rejects a request, sends the same confirmation twice or does not respond. Record which failures can be retried, need a person or must stop the journey.
Accessibility belongs inside the journey. The W3C accessibility evaluation guidance says no tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is required. Under WCAG 2.2, conformance covers the whole page, including versions shown at different screen sizes such as mobile, and all the pages needed for every step of a task. This readiness review uses that whole-journey scope; it does not certify WCAG conformance. A score can point to problems, not certify this prototype or replace testing with relevant people and devices.
These checks turn a vague concern into something specific to fix and show whether it reaches the core journey.
4. Can the business see and operate what happens next?
Customers experience performance as waiting, jumping content and delayed response - not as a technical score. Core Web Vitals provide signals for loading, interaction responsiveness and visual stability. They help teams inspect and monitor the experience, but they do not prove overall usability or predict a commercial result by themselves.
In one company’s month-long 50/50 landing-page test, Rakuten 24 reported improvements in conversion rate and revenue per visitor for its Core-Web-Vitals-optimised version. Those results belong to that case, not yours; use the example as a reason to measure your own essential journey, not as a forecast.
Measurement should follow the outcome. Google Analytics calls an action important to business success a “key event”. That could be a confirmed booking, qualified enquiry or purchase - not merely a click. Configuration alone does not make the choice meaningful or the data accurate. Run a known test and verify that customer confirmation, the business system and reporting agree.
Finally, move the knowledge from the person who ran the demo to the people who will operate the outcome. As IZZY practice guidance, hand over the state map, approved product rules, outside-service dependencies, known limitations, test evidence, reporting and recovery steps. Name one business owner who knows who approves changes, watches the release, responds to customers and starts recovery. If the experience connects to broader AI workflows, our AI pilot-to-production governance guide provides a deeper boundary.
5. Decide: launch, focused fix or rescue
The seven tests support a practical decision, not a score. Record what you observed, what remains uncertain and which limitation could affect the essential journey.
| Route | Evidence | Decision |
|---|---|---|
| Launch and monitor | Essential journey works; known limitations are minor; outcome and owner are visible | Release to a bounded audience and monitor |
| Focused fix | Offer, trust, accessibility, tracking or one journey has a contained problem | Fix the first meaningful break, retest, then launch |
| Pause and harden | Customer/data risk, repeated failure, unclear ownership or fragile architecture affects the core journey | Stop public exposure or acquisition spend and run a deeper review |
A rebuild is not the default. If the offer is unclear, rewrite it. If one form fails, repair and retest that path. If visual rules drift, align the components customers actually encounter.
Pause when the problem cannot be isolated or the consequence is serious. A journey handling payment, account or sensitive data may need product-specific review. NIST’s Secure Software Development Framework supports integrating secure-development practices across the lifecycle; it is not a launch approval. Where fragile architecture blocks a contained fix, our guide to the true cost of technical debt explains repair versus replacement.
Conclusion: speed to prototype changes the next question
AI tools reduce the distance between an idea and something people can try. That is progress. But visual plausibility is only the first kind of evidence.
Before launch, prove that a new customer can understand the offer, trust the experience, complete one important journey and receive confirmation. Then prove that the business can see the result and knows who acts when reality differs from the demo. The answer may be launch and monitor, a focused fix or a deeper review - not automatically a rebuild.
Bring the prototype. We’ll test the path to a real customer outcome.
Bring one prototype and one essential customer journey to a 30-minute scoping call. We will give you a bounded initial read on what is visible, what evidence is missing and whether the next step appears to be launch and monitor, a focused fix, a deeper review or no engagement yet.
The call is not a conversion forecast, accessibility certification, security audit or launch approval.
Frequently asked questions
Not by default. Clearer wording, consistent controls, a repaired form or reliable confirmation may solve a contained problem. Consider rescue work when the core journey remains fragile or consequential risk cannot be isolated.
No. Automated checks provide useful signals, but accessibility requires knowledgeable human evaluation and performance metrics do not prove the whole experience. Test the complete journey with relevant people and devices.
Choose the action closest to a real business outcome: a qualified enquiry, booking, purchase, onboarding completion or important account action. Follow it through confirmation and the business response.
Possibly, if the essential journey works, limitations are minor and an owner can monitor a bounded release. Do not use it to hide customer, data or repeated core-journey risk.
Hand over states, product rules, dependencies, known limits, test results, measurement and recovery contacts. The business owner should not need the builder beside them when the journey changes or fails.
Sources
- Canva Code 2.0 announcement
- Figma Help: Create and edit a Figma Make file
- Figma Help: Get started with Make kits
- GOV.UK Service Manual: Making prototypes
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI: Evaluating Web Accessibility Overview
- web.dev: Web Vitals
- web.dev: Rakuten 24 Core Web Vitals case study
- Google Analytics Help: About key events
- NIST: Secure Software Development Framework (SSDF) Version 1.1