You built something with Cursor or Lovable or Bolt, it works when you click through it, and now you are staring at a "Launch" button wondering if you are about to embarrass yourself. That feeling is correct to have. Knowing how to test an AI-built app before real users do is the single biggest thing standing between a smooth launch and a flood of "this is broken" emails.

I see this almost every week. A founder ships a polished-looking app, real people start using it, and within hours the cracks show: a button that does nothing, a signup that silently fails, a form that breaks the moment someone types something the AI never imagined. The founder did nothing wrong. They just never had a system for finding these problems first.

So let me give you that system. In this post I will walk you through a repeatable manual QA checklist you can run yourself, no coding required, to catch functional bugs, design glitches, and the weird edge cases that make an app feel broken. I will also be honest about the few things you should hand to a real developer instead of guessing.

What QA testing actually means (and why your app skipped it)

QA stands for quality assurance. Stripped of the jargon, it just means deliberately trying to break your own app before your users do. You go through every path a real person could take, including the dumb and unexpected ones, and you write down what goes wrong.

Professional teams do this constantly. They have testers, automated checks, and checklists. When you build with AI, none of that comes in the box. The AI hands you something that runs, and "runs" feels like "works." Those are not the same thing.

Here is the gap. The AI built and tested exactly one path: the one where everything goes right. A valid email. A working card. A fast connection. A user who clicks the buttons in the exact order intended. That is the demo. Real users are nothing like the demo, and the difference is where every bug lives.

Why AI-built apps are full of untested paths

The reason AI-built apps ship with so many hidden bugs comes down to how these tools think. They optimize for "make it look done," not "make it survive contact with humans."

When you prompt an AI to build a feature, it generates code for the obvious case. It rarely asks itself the questions a careful developer asks automatically:

  • What happens if this field is left blank?
  • What if the user clicks submit twice?
  • What if the network drops halfway through?
  • What if someone pastes 10,000 characters into a box meant for ten?
  • What if a logged-out person visits a page meant for logged-in users?

The AI does not handle these because you did not ask, and it does not volunteer. It produces the happy path and moves on. That is why the app looks finished and feels fragile at the same time.

There is a second trap. When something does break, founders paste the error back into the same AI and ask it to fix it. Sometimes that works. Often it patches the symptom and quietly creates a new bug somewhere else, because using more AI to fix AI-built code repeats the same blind spots that created the problem. This is part of what I call vibe coding debt: the untested corners pile up faster than you can see them.

Your app does not have a quality problem because you are not a developer. It has one because nobody has deliberately tried to break it yet.

How to test an AI-built app: the manual QA checklist

You do not need testing tools or technical skills for most of this. You need a notebook, an hour or two of focus, and a willingness to be mean to your own app. Work through these in order.

1. Test every core flow end to end

A flow is a complete journey a user takes to do one thing. Start by listing your app's main flows. For most apps that is something like: sign up, log in, do the main action, pay, log out.

Now do each one slowly, as a brand-new user, in a fresh browser window. Not the version you have been logged into for a week. A genuinely fresh start, because that is what your real first user sees.

For each flow, confirm:

  • Every button and link goes where it should.
  • Every form actually saves what you typed.
  • You get a clear confirmation when something succeeds.
  • You can get back out and start again cleanly.

Write down anything that feels off, even slightly. A flow that "mostly works" is a flow that breaks for someone.

2. Deliberately do the wrong thing

This is the part founders skip and the part that catches the most bugs. Go back through each form and flow, and behave badly on purpose.

  • Submit a form with every field blank.
  • Enter a fake email like notanemail and see if it complains or just breaks.
  • Type letters into a phone or price field.
  • Paste a huge block of text into a small box.
  • Click the submit button five times fast.
  • Hit the browser back button in the middle of a payment or signup.

What you are looking for is whether the app fails gracefully (a clear message like "please enter a valid email") or fails ugly (a blank screen, a spinning wheel forever, or a scary error full of code). Ugly failures are bugs. Write them all down.

3. Test the logged-out and wrong-user cases

This one matters more than it looks, because it overlaps with security. Open your app in a private or incognito window where you are not logged in. Then try to visit pages that should require an account by typing their web addresses directly.

If a logged-out stranger can reach a page meant for paying members, or worse, see another user's data, that is not just a bug. That is a hole. AI tools leave these doors unlocked constantly, because in the demo there is only one user and nobody is poking around. I wrote more about this in why your AI-built auth is probably broken, and it is worth a read if your app has accounts.

4. Check it on real devices

Your app looking perfect on your laptop tells you nothing about how it looks on a phone, which is where most of your users will be.

  • Open it on your actual phone, not just a shrunken browser window.
  • Try both portrait and landscape.
  • Check that buttons are big enough to tap and text is readable.
  • Test on a different browser than your usual one (if you use Chrome, try Safari or Firefox).

AI tools often build for one screen size and let everything else fall apart. Overlapping text, buttons off the edge, menus you cannot close. These are the glitches that make an app feel amateur even when the logic underneath is fine.

5. Test the empty and the overflowing states

Apps look great with exactly the right amount of content. They break at the extremes.

  • Empty state: What does a brand-new user see before they have added anything? A blank, confusing screen, or a helpful "get started" message?
  • Full state: Add a lot of data. Twenty items, a hundred, a very long name, an entry from a year ago. Does the layout hold? Does it slow to a crawl?

That slowdown is a preview of a bigger problem. Apps that feel fine with ten rows of data often grind to a halt with real volume, which is its own topic I covered in why AI apps break at scale.

6. Watch what happens when things go wrong outside your app

Your app depends on outside services: payment processors, email senders, login providers. Test what happens when one hiccups.

You cannot easily simulate all of these yourself, but you can check the basics. Turn off your wifi mid-action. Use a test card that is designed to be declined (most payment tools provide one). See whether the app tells the user something useful or just freezes. A frozen app with no explanation is how you lose a customer who would happily have tried again.

7. Keep a simple bug log

As you go, do not fix things on the fly. Just record them. A plain table is enough:

What I did          | What I expected      | What happened        | How bad
--------------------|----------------------|----------------------|--------
Signed up, blank    | "email required"     | white screen         | high
email               |                      |                      |
Tapped menu on phone| menu opens           | nothing happens      | high
Added 50 items      | list loads           | takes 8 seconds      | medium

This turns a vague feeling of "something's wrong" into a clear, prioritized list you can actually work through, or hand to someone who can fix it fast.

How to read your results

Once you have your list, sort it into three buckets:

  1. Launch blockers. Anything in a core flow (signup, payment, the main thing your app does), anything that exposes data, anything that shows a scary error. These get fixed before real users arrive. No exceptions.
  2. Embarrassing but survivable. Layout glitches on certain phones, awkward empty states, confusing wording. Fix these soon, but they will not sink you on day one.
  3. Nice to have. Polish, edge cases that almost nobody will hit. Schedule these, do not stress about them.

If your launch-blocker bucket is mostly empty, that is a great sign. If it is full, that is also useful to know now rather than during your launch.

What you can fix yourself, and what to hand off

Plenty of what you find, you can fix. Wording, layout tweaks, a missing confirmation message, a button pointing to the wrong page. These are safe to adjust, especially with the AI's help, as long as you re-test the flow afterward to make sure you did not break something next to it.

Be more careful with three categories. Anything involving who can access what (the logged-out tests in step 3) is a security question, and the cost of getting it wrong is your users' trust and data. Anything involving payments failing in confusing ways is worth a second set of eyes, because money bugs erode confidence instantly. And anything that breaks and you genuinely cannot tell why is a signal that the problem is deeper than the surface, which is exactly the kind of thing I get called in to untangle.

The honest line is this: testing reveals problems, but fixing some of them safely requires knowing how the pieces underneath fit together. Patching a security hole by guessing, or fixing one bug and creating two more, is how a launch-day list turns into a launch-day disaster.

Test before they do, not after

Here is what I want you to walk away with. The bugs are already in your app. That is not a knock on you or on the AI. It is just what happens when something gets built fast for the demo. The only question is whether you find them first or your users do.

Running this checklist puts you ahead of almost every solo founder I meet, because you stopped assuming "it runs" means "it works" and started deliberately trying to break it. That mindset alone catches most of the embarrassing stuff.

If you have run through your app, built your bug list, and you are looking at a handful of things that scare you (the security holes, the payment failures, the breaks you cannot explain), that is exactly where a real human review pays off. I go through AI-built apps every week, find what is fragile, and either fix it or hand you a clear plan so you know precisely what you are dealing with. If you would rather launch knowing your app is solid instead of hoping it is, let's talk about what yours needs.

Cover photo by Jakub Zerdzicki on Pexels.