How to get a vibe-coded app ready for customers

A working prototype shows that the basic idea can work. To put it in front of customers, you also need evidence that it protects their data, completes important tasks, and can recover when something fails.

We would check access, task completion, and recovery before deciding on a rewrite. Some prototypes can be improved one part at a time. Others need a larger change because important rules are scattered or the deployed system cannot be reproduced. The decision should follow the code and requirements, not the fact that AI helped write it.

TL;DR A prototype does not automatically need a rewrite. Check the customer workflow, permissions, recovery, monitoring, and running cost. Fix the gaps that prevent a safe launch.

Trace the critical customer journey

Choose the workflow that matters most: signing up, uploading a file, paying, receiving a result, or booking an appointment. Follow it through the browser, server, database, and external services.

Write down the expected result and how you verify it. Include failures between steps. If a payment succeeds but the app loses the response, what prevents another charge and how does the customer receive access?

That trace becomes the basis for the release review. It also exposes unnecessary complexity more clearly than a general request to "clean up the code."

Verify identity and data isolation

Test the journey as the intended user, another user, and an unauthenticated caller. Check API requests directly, not just which controls the interface displays.

Confirm that privileged credentials remain server-side and that server actions enforce authorization. For Supabase, review grants and policies using the official RLS guidance.

The security review covers those checks in more detail. A visually complete app should not proceed with a way for one customer to access another customer's private data.

Make deployment and recovery repeatable

The repository should contain the application and the definitions needed to build it. Document required configuration without committing secrets. Use a lockfile and controlled dependency updates so another person can reproduce the build.

Review database migrations against existing data. A new application version and a schema change may not roll back together. Decide how to recover before applying destructive changes.

Restore a backup into an isolated environment and verify that the application can use it. Include uploaded files and other required stores, not only the main database. Define how to reconcile actions that happened after the backup or during an interrupted workflow.

Track completed tasks as well as errors

Track failed requests, latency, and availability. Also track whether the customer completed the intended job. A successful HTTP response can still contain an unusable result.

For AI behavior, build representative evaluations and review important failure categories. OpenAI's evaluation guidance recommends task-specific and ongoing evaluation. Anthropic's agent guidance reinforces the value of simple workflows and clear tool boundaries.

Keep traces useful without logging unnecessary personal data. Name an owner for alerts and give that person a tested way to stop risky actions or divert work.

Estimate the running cost before launch

Measure the complete workflow, including retries, storage, background jobs, external tools, and human follow-up. Convert rates carefully and keep the expected request frequency explicit.

Do not derive a monthly budget from registered users alone. Use active usage and the distribution of tasks. Put limits around expensive operations and test what customers experience when a limit is reached. The AI cost guide provides the accounting structure.

Turn findings into a release decision

Boundary	Evidence to bring
Access	Expected permissions work; cross-user attempts fail
Core workflow	Correct external outcome, including retry cases
Deployment	Reproducible build and reviewed migration path
Recovery	A completed restore and reconciliation exercise
Operations	Useful alerts, an owner, and a fallback
Economics	Measured usage and an explained cost forecast

Fix issues in related batches, then verify the affected workflows. Avoid a broad rewrite unless the review shows that the current structure makes those requirements impractical to meet.

Launch to a restricted audience with clear support and rollback arrangements. Expand after the evidence supports the next level of usage. Start with one launch requirement you have not checked, such as restoring a backup, and demonstrate that it works.

Sources

• Supabase: Row-level security
• OpenAI: Evaluation best practices
• Anthropic: Building effective agents