You can have a perfect app and zero users
Short answer
Before launch, test the parts that would embarrass you or cost you a user: signup, login, payment and the first five minutes in the product. Once those hold up and nothing loses data or money, stop polishing. A product nobody knows about gets no users however well it works, so the next week is better spent getting seen.
A lot of founders who build an app fast come to BetterQA to get it tested before launch. We test it, and we also tell them something a testing company is not supposed to say. Tudor Brad, our co-founder, puts it this way: "They can have the best product in the world, but if nobody knows about the product, nobody's going to use it."
This guide is the advice we give them: what testing can and cannot do for a new product, what to test before launch, and where to stop.
What testing can and cannot do for a new product
Testing protects the people who show up. It does not bring them. Both halves matter, and founders who have just built something tend to forget the second one.
| Testing does | Testing does not |
|---|---|
| Finds the signup that fails on one browser | Tell anyone your product exists |
| Catches the payment that charges twice | Prove that people want what you built |
| Stops data disappearing on refresh | Replace talking to the first ten users |
| Checks that one user cannot see another user's data | Make a feature nobody asked for worth building |
So the goal before launch is not a perfect product. It is a product that does not lose the people you worked hard to get.
What to test before launch
A simple filter: test whatever would embarrass you if your first serious user hit it, or whatever would make them leave and not come back.
- Signup and login. Including the email that confirms the account, password reset, and signing in from a second device. A user who cannot get in is a user you never meet.
- Payment. A card that works, a card that is declined, a refund, and the receipt. Money mistakes cost trust faster than anything else.
- The first five minutes. What a new user sees with no data yet, and the one action they came to do. If that is confusing, nothing else gets seen.
- Data that has to stay put. Save, reload, log out, log back in. Then check that one user cannot open another user's records by changing a link.
- Phones. A small screen and a slow connection. Many first visits come from a link opened on a phone.
- Anything that sends something. Emails, notifications and invites, so nothing goes to the wrong person or arrives twice.
That list is short on purpose. For most first versions it is a few days of focused testing, not months.
Where to stop polishing and start getting seen
Signs that you are polishing instead of launching:
- You are fixing screens nobody outside the team has opened.
- You are testing every browser and device before you have ten users.
- You are perfecting features that no customer has asked for.
- The launch date keeps moving for reasons that are not bugs in the list above.
Once the critical paths hold and nothing loses data or money, ship it. The bugs real users find tell you what actually matters, and they are usually not the ones you would have guessed. Put the time you save into being found: a launch post, the communities your users already read, and direct conversations with the first people who sign up.
If you built it fast, check the unhappy paths
Products put together in weeks, often with AI coding tools, usually work well on the path the builder tried. The problems sit off that path: what happens on a wrong password, an expired link, a double click on "pay", or a user who opens someone else's page by changing a number in the address bar. Leaked keys in code that runs in the browser are another common find. These are the checks worth paying someone outside your team for, because the person who built the path is the person least likely to wander off it.
We wrote more about this on our page on testing for teams that build with AI tools.
App launch checklist for founders
- A new user can sign up, confirm their email and log in on a phone and a laptop.
- Password reset works, and the link expires.
- A payment succeeds, a declined card shows a clear message, and nobody is charged twice.
- A new user knows what to do in the first minute.
- Data survives a reload, a logout and a second device.
- One user cannot see another user's data.
- No secret keys are visible in the page source.
- Error messages tell people what to do next.
- You know how you will hear about the bugs users find after launch.
- You have a plan for how the first hundred people will hear about the product.
The last item is not a testing item. It is on the list because it is the one founders most often skip.
Why a QA company is telling you not to over-test
We would rather you launch, find your users and come back when there is more at stake than spend your runway making something perfect that nobody sees. Testing should grow with your product: a focused check of the critical paths before launch, then more as users, payments and data start to depend on it.
Frequently asked questions
Launching soon?
Tell us your launch date. We test the paths that matter before it, so you can spend the rest of your time getting users.
Book a call Testing for fast-built appsNeed help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
