What Should I Test Before Taking Real Users? The Short List

Test the six paths where a failure loses money, data or a user you cannot get back: sign-up and login, the core workflow, payments in test mode, whether one user can see another's data, the mobile layout, and error states. Run them on a real phone and a laptop, with wrong passwords, declined cards and empty inputs. Leave exhaustive edge cases and load testing for after you have traffic.

If you would rather have that list run for you before go-live, see how RAITHub would test this below, or the pre-launch QA overview.

Why these paths and not everything?

Because before you have users, your job is to rule out the failures that are expensive, not to chase every bug. A failure in the core paths does more than annoy: it loses the customer, leaks data, or takes money wrongly, and it poisons the early signal you launched to collect. A bug on the fifth settings screen does none of that. Testing everything equally before launch wastes the time you need to ship. The deeper version of this list for SaaS is in how to test a SaaS application.

What is on the must-test list?

Six areas, in priority order. If you only have a day, start at the top.

Area	Why it matters before real users	The core check
Sign-up and login	A broken front door loses every user before they see the product	Register, log in, log out and reset a password, on a phone and a laptop
The core workflow	It is the reason users arrive; if it fails, nothing else counts	Complete the main job end to end, including empty and error states
Payments	Real money turns a bug into a refund, a chargeback or lost trust	Successful, declined and refunded payments in test mode, plus a double payment
Data access	One user seeing another's data is a breach, not a bug	Confirm a logged-in user cannot read or change another account's records
Mobile layout	Most early traffic is mobile, and rushed layouts break there	Walk the core workflow on a real phone, not a resized browser
Error states	Strangers hit paths you did not build for; a blank screen loses them	Wrong password, expired session, lost connection and bad input show a message, not a crash

If the app was built with an AI coding tool, these are exactly the paths that tend to ship broken; the AI-built SaaS launch checklist covers them in that context, and the full general walkthrough is the pre-launch QA checklist.

How deep should each check go?

Deep enough to cover what a stranger will do, not every theoretical case. For each path, test the happy route once, then the two or three ways a real user breaks it: the wrong input, the declined card, the back button, the second tab. The highest-value single test is the cross-user access check, which needs two accounts and a deliberate attempt:

import { test, expect } from '@playwright/test'

test('a user cannot read another user record', async ({ request }) => {
  const res = await request.get('/api/records/' + process.env.OTHER_USER_RECORD_ID, {
    headers: { Authorization: 'Bearer ' + process.env.MY_TOKEN },
  })
  expect([403, 404]).toContain(res.status())
})

If flipping a permission check turns no test red, your suite is not protecting you yet.

What can wait until after launch?

• Exhaustive cross-browser coverage. Cover the browsers your users actually use, widen later.
• Heavy load and performance testing. You do not have the traffic; a quick "is it painfully slow" check is enough for now.
• Rare edge cases far from the core workflow. They can have bugs until you have users who reach them.
• A full accessibility audit, unless legally required; a keyboard-and-contrast smoke check is a reasonable floor.
• A large automated suite. A few smoke checks on the core paths are enough to launch; deep coverage pays back once you iterate.

Buy, build or hire?

Route	Choose this when
Test it yourself with this list	Pre-seed, a simple product, and you will run the paths carefully on a real device
A freelancer for one pass	You want human eyes on many devices for one launch and can supply the plan
A fixed-price pre-launch audit	You want a ranked bug report over the critical paths before real users, with fixes
A monthly QA plan	You are past launch and shipping often enough to need testing on every release

If the real question is whether it is ready at all, see how to tell if your app is ready to launch.

How RAITHub would test this

RAITHub runs exactly this list as a fixed-scope pre-launch audit.

• Scope: sign-up and login, the core workflow, payments in test mode, data access, mobile layout and error states, on desktop and real phones.
• Smoke checks: a basic security pass against OWASP guidance, plus accessibility and performance smoke checks.
• A ranked report: every issue with severity, reproduction steps and a suggested fix, split into fix-before-launch and can-wait.
• Fixes, by you or RAITHub: fix from the steps, or have the same engineers fix them under a separate fixed quote.

Timeline: the audit is fixed in scope and dates before it starts. For proof of the method, PropDesk runs 1,024 automated tests and Sundor Skin 530+. There is no standalone pre-launch case study yet, so judge it on the free call and a written scope. See QA as a Service. The next step is a free 15-minute audit, then a written fixed quote; RAITHub publishes no rates.

Letting real users in soon? Request a pre-launch audit.

Frequently asked questions

What should I test before taking real users?

Sign-up and login, the one core workflow, payments in test mode, whether one user can see another's data, the mobile layout, and error states. Run them on a real phone as well as a laptop, with wrong passwords, declined cards and empty inputs.

What is the single most important thing to test first?

Sign-up and login, because a broken front door loses every user before they reach the product. Right after it comes the core workflow and the check that one user cannot read another's data, which is the most expensive failure to find after launch.

Can I launch without testing everything?

Yes, and you should. Test the paths that lose money, data or trust, and defer exhaustive cross-browser coverage, load testing and rare edge cases until you have users. Testing everything equally before launch wastes the time you need to ship.

How do I test that users can't see each other's data?

Create two accounts and deliberately try to read one account's records while logged in as the other, through the app and directly against the API. It should be refused. This needs a conscious attempt, which is why it is the check people most often skip.

Do I need automated tests before launch?

Not a large suite. A few smoke checks on the core paths are enough to launch, and deep automated coverage pays back once you are shipping often. Manual, careful testing of the must-test list matters more than automation at the first launch.

What happens if I find a serious bug right before launch?

Decide with the evidence: delay and fix, launch with a known limitation and a workaround, or have the fix done for you. A ranked bug report makes that a deliberate choice rather than a panic, which is the whole point of testing before real users arrive.