Should I be unit testing during prototyping or preparing for beta?

Test when preparing for a beta and skip tests while prototyping, because beta testers put their own data into the product and a prototype runs on fake data. Before a beta, test the main paths and every save of tester data at the API level.

What should I test before a beta launch?

Before a beta launch, test signup, login, the core action, and each endpoint that saves tester data. Each save test creates a record, changes one field, and reads back every field.

Do beta testers replace automated tests?

Beta testers do not replace automated tests: they report a broken page within a day, but they cannot undo records that broken code saved. Testers find new bugs, and automated tests stop fixed bugs from coming back.

Should I test a paid beta?

Yes, a paid beta needs tests of the charge path before the first payment: the amount, the plan the tester gets, and a repeated payment request. A double charge needs a refund, so the framework gives Test mandatory for the charge path.

Should I write tests before the beta release?

Verdict

Yes

Yes, before the first beta invite, write automated tests in CI for the main paths that beta testers run and for every endpoint that saves their data, and check screens that beta feedback will redesign in the browser instead.

Why

Blast radiususers
Change frequencyconstantly
Detectabilitysame-day
Reversibilitywith-effort
Test costmoderate

Yes, write tests before the beta release; rule R11 gives Test for my typical case, a web product opened to 30 invited testers who use it with their own data for six weeks. Blast radius is users, because testers see errors and lose work they entered. Change frequency is constantly, because I ship fixes from tester feedback several times a week. Detectability is same-day: beta testers expect bugs and report a broken page within a day. Reversibility is with-effort, since records that broken code saved need a repair script. Test cost is moderate, about an hour for an API-level test of one path.

When the decision changes
When	Decision	Why
Beta testers work only on sample data that you reset every week, and store nothing of their own	Test minimally: one end-to-end test of the main path that runs before each beta build	Reversibility falls to trivial: the weekly reset removes any wrong record, and no tester's work is lost
The beta is five colleagues who try each build on a video call while you watch, on sample data	Do not test the beta build yet; note each failure you see and fix it after the call	Blast radius falls to internal, Detectability to immediately and Reversibility to trivial: you see each failure as it happens
The beta charges testers a discounted price by card	Test mandatory: the charged amount, the plan the tester gets, and a repeated payment request	Blast radius rises to money and Reversibility to costly: a double charge needs a refund and costs a tester's trust
Beta testers store client records that other accounts must not read	Test mandatory: for each record type, one test that a second account is denied the first account's records	Blast radius rises to safety-or-legal and Detectability to never: a leaked record looks like a normal page
The beta's main path runs through a paired hardware device that CI cannot reach	Test minimally: test the save code with recorded device input, and try the device by hand before each beta build	Test cost rises to heavy: a test through the real device needs the hardware in CI

What breaks if you don't test

During a beta the code changes fastest while real data first flows through it. A fix for one tester's complaint breaks a save that another tester relies on, and wrong records pile up until someone writes in. In my practice, testers forgive one broken week and stop logging in after the second, and the feedback the beta exists to collect stops with them.

What you lose if you over-test

Browser tests pinned to screens that beta feedback will redesign break at each redesign, and you fix selectors instead of the bugs testers reported. A coverage target pushes tests onto features the beta may show nobody uses.

How to test

Test at the API level, below the screens, in CI, as the Practical Test Pyramid describes:

List the paths every tester runs: signup, login, the core action, and each save of tester data.
For each save, write a test that creates a record, changes one field, and reads back every field, for example with the FastAPI test client.
Add one browser test from signup to the core action with Playwright.
Run the tests on every push, and block the beta build when one fails.
Add a regression test for each bug a tester reports.

Procedure and references

When the answer changes

Testers work on sample data you can reset, so a bug leaves nothing behind.
The beta starts charging, or testers store records other accounts must not read.
The testers are colleagues you watch on a call.

Real incident + Code example

The rename that zeroed the stock counts

On an inventory product I worked on, we opened an untested beta to 25 small shops that counted their stock in the app. In the fourth week I rewrote the endpoint that updates a product to speed up saves. The new code read a missing quantity as zero, so a shop owner who renamed a product also set its stock to zero. The first shop wrote in that afternoon, and the revert took ten minutes. The repair took two days: we rebuilt 340 stock counts in nine shops from the audit log, and two shops left the beta. The test I added after the repair renames a product and reads its stock back:

def test_renaming_a_product_keeps_its_stock(client, shop):
    created = client.post(
        f"/shops/{shop.id}/products",
        json={"name": "Oat milk 1L", "quantity": 24},
    ).json()

    client.patch(f"/products/{created['id']}", json={"name": "Oat milk 1 L"})

    saved = client.get(f"/products/{created['id']}").json()
    assert saved["name"] == "Oat milk 1 L"
    assert saved["quantity"] == 24

Should I write tests for an MVP?Yes
Should I test a prototype?No
Should a startup write tests?Yes
Should I skip tests when the deadline is tight?Code under test: Yes

FAQ

Should I be unit testing during prototyping or preparing for beta?: Test when preparing for a beta and skip tests while prototyping, because beta testers put their own data into the product and a prototype runs on fake data. Before a beta, test the main paths and every save of tester data at the API level.
What should I test before a beta launch?: Before a beta launch, test signup, login, the core action, and each endpoint that saves tester data. Each save test creates a record, changes one field, and reads back every field.
Do beta testers replace automated tests?: Beta testers do not replace automated tests: they report a broken page within a day, but they cannot undo records that broken code saved. Testers find new bugs, and automated tests stop fixed bugs from coming back.
Should I test a paid beta?: Yes, a paid beta needs tests of the charge path before the first payment: the amount, the plan the tester gets, and a repeated payment request. A double charge needs a refund, so the framework gives Test mandatory for the charge path.