Free. No email wall.

The beta-readiness checklist

21 concrete checks before your first hundred users, from the same eight dimensions every Readiness Report covers. Work through them with your agent: most are a question you ask it, then a thing you verify yourself.

The ground rule, same as our audits: honesty over reassurance. UNKNOWN is a valid answer. Write it down and keep moving. An unknown you’ve named is progress.

Ticks aren’t saved between visits. Print this page or copy the items into your notes.

Security

Can a stranger break, read, or take what they shouldn't?

Signed-out visitors can't reach signed-in pages or data.Sign out, then paste a private page URL and call a private API route directly. Both should refuse. Not render, not return data.
No secrets in the browser or the repository.View page source and search for key-like strings (sk_, secret, token). Then ask your agent to scan the repo, including history. Keys belong server-side, in environment variables.
Database rules restrict each table by user.On Supabase, Firebase, or similar: open the rules or row-level policies and read them line by line. "Allow all," or a policy that exists but is disabled, is a finding.

Accounts & access

Can users sign in, recover, and leave cleanly?

Password reset works end to end.Request a reset with a real address, follow the email, set a new password, sign back in. All the way through, not just the first screen.
People can leave.Create a throwaway account and delete it. Or confirm there's a real, answered channel where a user can ask to be deleted.
Sessions end when they should.Sign in on two devices and change the password on one. Note what happens to the other session, and decide whether that's what you want.

Data stewardship

Is user data stored deliberately, backed up, and recoverable?

Backups exist, and you've seen one restore.Find the backup setting for your database and confirm it's on. Better: restore a backup into a scratch project once, so the first time isn't during an emergency.
You can list the personal data you hold.Write down every personally identifying field you store: emails, names, addresses, photos. If the list surprises you, keep the list; you'll want it for your privacy policy.
One deleted record isn't a crisis.Know how you'd bring back a single user's accidentally deleted data: point-in-time restore, an undelete flag, or an honest "we can't" you're willing to say out loud.

Legal & privacy

Does the product meet baseline GDPR/CCPA expectations for a public beta?

A privacy policy exists and tells the truth.It's linked from your footer, and what it says you collect matches the data list you just wrote. A short, honest policy beats a long, borrowed one.
Terms exist, and deletion requests get answered.A terms page is linked, and an email asking "please delete my account" reaches a mailbox someone actually reads.

Payments

If money moves, does it move correctly in every case?

Test money and live money never mix.Confirm which mode production runs in and that test keys can't appear there. Then make one real purchase with a real card and refund it. No payments in your product? Check this off and move on.
A payment that arrives while your app is down still counts.Payment providers retry webhooks. Confirm your handler records the order correctly when it's called late, or twice.

Reliability & operations

When something fails, will you know, and can you recover?

Errors reach you, not just your users.Ask your agent: "Where would I see yesterday's production errors?" If the answer is "nowhere," wire up error monitoring, or at minimum, find the logs.
Failure looks calm from the outside.Force an error on purpose: bad input, a missing record. Users should see a plain-language message, never a stack trace or a blank page.
You can put the previous version back.Write down the exact steps to roll back a bad deploy. If they're a mystery, rehearse them once while nothing is on fire.

Product surface

Do the unglamorous states hold up: empty, loading, error, and mobile?

Empty states explain themselves.Open every screen with a brand-new account. Blank panels should say what belongs there and what to do first, not just render nothing.
The first run works on a real phone.Walk sign-up to first value on an actual device, over cellular, not a resized desktop window on office wifi.
A keyboard can drive the main flow.Tab through sign-in and your core action. Focus should always be visible, and nothing should be reachable only by mouse.

Performance

Is anything slow enough to lose a first-time user?

Your heaviest page survives real data.Load your busiest list with a hundred-plus records. It should paginate or stay quick, ideally both.
Nothing enormous ships to the browser.Run PageSpeed Insights on your main pages and look at the largest files it flags. Unoptimized images are the usual suspects.

If you checked everything: you’re in better shape than most products that launch. Go get your hundred users.

If you hit a wall of unknowns: that’s not failure. That’s a map of the last stretch. The Readiness Report is the deep version of this list, and free too.

Turn the unknowns into a work list.

The Finishing Pass turns your report into the exact fixes, in order, each one proven, until your product is ready for real users. It starts with The Readiness Report, free: your own agent runs the audit, no upload, no payment to begin.

Get your Readiness Report

Your code stays with you, and the free report needs no upload.