From Vibe Coding to Viable Product: A Designer’s Quality Gate for AI-Built Apps

A founder can test an idea without first assembling a full product team. A designer can make a complex interaction tangible instead of explaining it through static frames. An internal team can automate an annoying workflow and learn whether it deserves further investment. This is not a toy use case. Anthropic’s 2025 analysis of 500,000 coding interactions found that 79% of conversations with Claude Code were classified as automation, and user-facing development was among the most common uses. Figma, GitHub, Vercel, and other platforms have all expanded tools that move people more quickly from description to functioning software.

The danger begins when speed to demo is confused with readiness to ship.

An AI-built app can look convincing while hiding weak authorisation, inaccessible controls, brittle data and missing edge cases. The 2025 Stack Overflow Developer Survey captures the tension: 84% of respondents used or planned to use AI tools, yet more distrusted AI accuracy than trusted it.

The answer is not to reject vibe coding. It is to give it a quality gate.

First, name the stage correctly

Teams get into trouble when a prototype quietly becomes production. Use three explicit stages.

Prototype: Can this idea work?

A prototype reduces uncertainty with sample data, mocked integrations and simplified flows. It tests a proposition, interaction or technical possibility. It should not hold sensitive data, make irreversible decisions, accept real payments or imply reliability it has not earned.

Pilot: Does this work for a limited real audience?

A pilot serves a limited real audience under controlled conditions. It needs authentication, permissions, backups, error monitoring, privacy decisions, direct support and a rollback plan. “Beta” is not a substitute for these controls.

Production: Can people depend on this?

Production software must protect data, handle load and failure, meet accessibility requirements, support users and remain maintainable.

The key question changes at each stage:

• Prototype: Is the idea worth pursuing?

• Pilot: Can we manage real-world use safely?

• Production: Can users and the business rely on it repeatedly?

If the team cannot agree on the stage, it is not ready to advance.

What AI builders do well and what they conceal

AI builders are strong at scaffolding familiar structures and rapid iterations: forms, dashboards, CRUD workflows, landing pages, API connections and component patterns.

But their fluency creates a “looks done” problem. Generated applications often optimise for the visible success path. The prompt says “users can create an account and save a project,” so the app demonstrates that outcome. It may not ask:

• Can one user access another user’s record by changing an ID?

• What if payment succeeds but confirmation times out?

• What does a screen reader announce after an error?

• What happens when an external API is slow or malformed?

These are not finishing details. They are the product.

OWASP Top 10: 2025 leads with Broken Access Control, Security Misconfiguration and Software Supply Chain Failures, and also covers insecure design, authentication, logging and exceptional conditions, risks easily hidden behind a polished interface.

The viable-product quality gate

Before advancing an AI-built app, score eight categories from 0 to 2:

• 0 — Fails: missing, unknown or demonstrably unsafe

• 1 — Conditional: partly addressed; documented work remains

• 2 — Passes: tested, evidenced and owned

Do not advance with a zero. Security, privacy and critical-task reliability require a full score before production.

1. Desirability: Is there evidence of a real need?

Build speed is not evidence of demand. Test a defined user and recurring problem through representative people performing real tasks. Look for behaviour, not compliments.

Evidence to require: observed task sessions, clear problem statement, defined target user, and a reason this solution is better than the current workaround.

2. Usability: Can users complete the critical journey?

Test the top three jobs without coaching, including first use, repeat use, interruption and recovery. Watch for hesitation, misinterpretation and accidents.

Evidence to require: task-completion results, documented usability issues, clear navigation, useful validation, and tested empty, loading, error and success states.

3. Accessibility: Can people perceive and operate it?

WCAG 2.2 is the current W3C recommendation and is designed to be tested through a combination of automation and human evaluation. Automated scans are useful, but they cannot confirm that focus order makes sense, labels are meaningful or an interaction is understandable.

Evidence to require: keyboard-only testing, visible focus, semantic headings and controls, sufficient contrast, appropriate labels and error messages, target sizes, zoom/reflow behaviour, reduced-motion handling and at least a basic screen-reader pass.

Aim for WCAG 2.2 AA as a practical baseline unless a stricter standard applies.

4. Security and privacy: Is access controlled and data minimized?

Generated applications need the same threat thinking as hand-written ones. Test authentication separately from authorization, then review dependencies, secrets, storage, logs, uploads and admin paths.

Evidence to require: role and permission matrix, server-side authorization tests, secrets kept out of code and client bundles, dependency scanning, input validation, rate limits where needed, secure session handling, privacy notice, retention rules and a security review against OWASP Top 10:2025.

For payments, health, identity, children’s data or other regulated information, involve security and legal specialists before a real-user pilot.

5. Reliability: Does it fail safely?

A product must behave when dependencies fail, users double-click, connections drop, and data arrives late or twice.

Evidence to require: graceful errors, retry and idempotency strategy, backup and restore test, transaction integrity, timeouts, fallback behaviour, clear status communication and a rollback plan.

For AI features, test incorrect, harmful and uncertain outputs. Define when the system should refuse, ask for clarification, show sources or require human approval.

6. Performance: Is the experience responsive in real conditions?

Test ordinary mobile hardware and imperfect networks. Google’s Core Web Vitals thresholds are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less, measured at the 75th percentile.

Evidence to require: field or realistic test data, acceptable response times for critical actions, optimized media, bounded bundle size, database-query review and a plan for traffic growth.

7. Observability and support: Will you know when it breaks?

Instrument critical journeys, failures and dependencies before the first alert becomes a user complaint. Keep logs useful without leaking sensitive information.

Evidence to require: error tracking, uptime checks, structured logs, analytics for key outcomes, alert ownership, support contact, incident process and enough product context to reproduce a problem.

Measure completed outcomes, not just clicks.

8. Maintainability: Can another person safely change it?

Before production, someone must understand the generated system, its architecture and its dependencies well enough to own it.

Evidence to require: source control, reviewed dependency list, setup instructions, environment separation, database schema and migrations, tests for critical logic, coding conventions, named technical owner and a documented deployment process.

“Ask the AI how it works” is not maintainability.

A quick teardown: the AI-generated booking app

Imagine a generated booking app with a polished happy path. The gate quickly exposes what the demo conceals: no evidence about whether users choose a service, staff member or location first; no timezone or rescheduling flow; a date picker that fails keyboard use; untested record-level permissions; duplicate bookings on repeated submission; no alert when confirmation email fails; and no migration, test or deployment documentation.

It may be a useful prototype, but it is not a viable pilot. The gate prevents visual polish from overruling evidence.

When a designer should bring in an engineer or specialist

Designers can own the gate without pretending to own every technical answer. Bring in an engineer or relevant specialist when the app handles sensitive data, money, identity, health or legal rights; controls shared or paid resources; depends on complex integrations; performs irreversible actions; has unresolved accessibility barriers; or cannot be explained, tested and deployed by someone other than its original builder. Review depth should match consequence.

The pre-ship checklist

Before a production release, confirm:

• The stage: prototype, pilot or production, is explicitly agreed.

• Representative users have completed critical tasks without coaching.

• Empty, loading, error, offline and recovery states are designed.

• WCAG 2.2 AA checks include keyboard and screen-reader testing.

• Authentication and record-level authorization are separately tested.

• Secrets, dependencies, uploads, logs and admin routes have been reviewed.

• Backups have been restored successfully, not merely configured.

• Duplicate actions, retries and external-service failures are handled safely.

• Core Web Vitals and critical API/database timings are measured.

• Errors, uptime and completed product outcomes are monitored.

• Support and incident owners are named.

• Critical logic has automated tests and human code review.

• Another qualified person can set up, deploy and change the system.

• High-impact areas have received specialist security, legal or accessibility review.

Speed should buy learning, not permission to skip responsibility

Vibe coding lets more people test ideas in working form. Designers can explore behaviour earlier, reduce speculative debate and discover problems before investing heavily.

But a shorter path to functioning software is not a shorter path to trust.

A viable product solves a real problem, works for different people, protects them, survives failure and can be responsibly operated.

Use AI to compress production. Spend the saved time on evidence, edge cases, accessibility, security and ownership. That is how an experiment becomes dependable.