Skip to content
Auwave
← All articles

Product & engineering

Built an app with AI? Check these things before you launch.

The first version is working. You can sign in, click around, and show it to someone. That is real progress. But a working demo and a product people can depend on are two different milestones.

What people mean by “vibe coding”

The phrase usually means building software by describing what you want to an AI tool and iterating on what it produces. It can be a useful way to explore an idea. The risk is treating “it looks right” as proof that the whole system is right.

Verification matters. In the 2026 Stack Overflow Developer Survey, 48% of respondents to the AI-trust question said they trust AI when they can easily verify its output. That is a developer survey, not a safety rating for your app.

Before inviting real customers, work through the checks below with someone who can inspect the code and infrastructure—not just the screens.

1. Check who can see and change data

Create two test accounts. Give each one its own records. Try to open an account’s private record while signed in as the other account. Then try while signed out.

Hiding a button is not access control. The server needs to check permission on every sensitive request. Review file downloads, admin actions, and exports as well as ordinary pages.

Keep private keys out of browser code. Know which services receive customer information. Use test data while you investigate, and only collect information the product actually needs.

2. Try the things your demo avoided

Use an empty form. Enter an unusually long name. Lose the connection halfway through an action. Click the submit button twice. Open the product on a small phone and navigate with only a keyboard.

For a paid product, use the payment provider’s test environment. Check failed payments, duplicate events, cancellation, and the difference between a successful checkout screen and a confirmed payment on the server.

A useful test

When an action fails, can a user understand what happened and safely try again—without duplicate records or charges?

3. Make recovery part of the plan

Take a backup, then practise restoring it in a safe test environment. Write down how to undo a bad release. Set up error reporting that tells a responsible person when something breaks.

Keep the source code in an account your business controls. Document where it runs, which services it uses, and how to deploy it. Do not leave this knowledge inside one person’s chat history.

4. Launch to a small group first

Invite a few people who represent your intended users. Watch them complete the main task without coaching. Notice confusing labels, dead ends, and places where they expect something different.

  • Agree which issues must be fixed before a wider release.
  • Set a spending alert for hosting and usage-based services.
  • Choose who will respond to support requests.
  • Re-test the main journey whenever you release a change.

This checklist is a starting point, not a complete security audit. Products handling sensitive data or complex permissions need a deeper review. Keep the speed AI gives you; add the checks that let you trust the result.

Sources & further reading

Original guidance from the Auwave team, with these references for context.

Have a prototype you want to launch?

We can review what works, what needs attention, and what to do next.

Explore how we can help