Verdict
Yes
Yes, a startup with customers should test the paths that keep them, such as signup, login and the core action, in CI, and check screens that change every week in the browser instead.
Why
- Blast radiususers
- Change frequencyconstantly
- Detectabilitysame-day
- Reversibilitywith-effort
- Test costmoderate
Yes, a startup with customers should test the paths that keep them; rule R11 gives Test for my typical case, a seed-stage team of three developers shipping a web product to paying customers. Blast radius is users, since customers meet a broken signup or core feature, and Change frequency is constantly, since the product changes in most weeks. Detectability is same-day, because early customers are few and write to the founders. Reversibility is with-effort: a revert is quick, but records saved by broken code need a repair script. Test cost is moderate, about an hour for an API-level test of one path.
| When | Decision | Why |
|---|---|---|
| A clickable demo for investor meetings that no customer logs into, deleted after the round | Do not test the demo; click through it once before each meeting | Blast radius falls to internal, Detectability to immediately and Reversibility to trivial: only the founders click through the demo, and it stores nothing |
| The startup's code charges cards, applies discounts, or computes invoices and payouts | Test mandatory: cover every amount and boundary, and have a second person review the tests | Blast radius rises to money and Reversibility to costly: a wrong charge ends in refunds and lost customers |
| The code decides which customer account may read which records | Test mandatory: test allowed, denied and cross-account requests | Blast radius rises to safety-or-legal and Detectability to never: a leaked record raises no error |
| A feature that stores nothing runs behind a flag that the team turns off in one click | Test minimally: one test of the feature's main path, and one that the old flow works with the flag off | Reversibility falls to trivial: turning the flag off removes the failure and leaves nothing behind |
| A change touches only page layout or copy, and the developer checks the page in the browser before merging | Do not test the layout; look at the page in the browser and in code review | Detectability moves to immediately and Reversibility to trivial: the developer sees the fault before merging |
| The team imports a new customer's spreadsheet into the product once, at onboarding | Test it differently: run the import on a copy, compare totals with the spreadsheet, and keep a backup | Change frequency falls to once: a test in the suite would never run again |
What breaks if you don't test
A flow that changes every week gets a new chance to break every week. A pricing change renames a plan field, and checkout fails for customers on the old plan. The founders hear of it from a customer email the next morning, while paid ads keep sending visitors to the broken form. Later, developers stop refactoring code they fear to touch.
What you lose if you over-test
A browser suite that clicks through every onboarding screen breaks at each redesign, and a developer spends the next morning fixing selectors. A coverage target pushes tests onto admin pages and experiments the team deletes within a month. Unit tests that mock every dependency pass while the real database query fails.
How to test
Test the paths that keep a customer at the API level, in CI:
- List the paths that keep or charge a customer: signup, login, the core action and payment.
- Write an integration test for each path against a real database, below the screens, so a redesign does not break it. The Practical Test Pyramid describes what each level costs.
- Add one browser test from signup to the first core action with Playwright.
- Add a regression test for each bug a customer reports, and block the deploy when a test fails.
Procedure and references
When the answer changes
- The code charges money or decides who may read whose data.
- Nobody outside the team uses the product yet.
- A contract or a standard such as PCI DSS requires test evidence.
Cost estimate
Three tests against one broken day of signups
Numbers I assumed for a seed-stage B2B product:
| Item | Assumption | Cost |
|---|---|---|
| Write the tests | Signup, login and core action, 1 hour each at $80 | $240 |
| Keep them working | The flow changes every two weeks, 30 minutes each time, for a year | $1,040 |
| Lost customers | Signup broken for 24 hours, 30 signups a day, 3% become $50-a-month customers for a year | $540 |
| Wasted ads | One day of ad spend at $150 | $150 |
| Repair | 4 developer hours at $80 for the hotfix, data repair and replies | $320 |
The tests cost $1,280 in their first year, and one broken day costs $1,010, so they pay off at two caught breaks a year in 26 changes to the flow.
Related questions
FAQ
- Should early-stage startups write unit tests?
Yes, early-stage startups with customers should write tests, mostly API-level tests of the main paths rather than unit tests of every function. Add unit tests for prices, dates and permissions, where a wrong value looks plausible.
- When should a startup start writing tests?
A startup should start writing tests when the first customer depends on the product. A demo that only the founders use needs a click-through before each meeting instead of tests.
- Do tests slow a startup down?
Tests of the main paths cost a startup little: three API-level tests take about 16 hours a year by my estimate. Tests pinned to screens that change every week slow a team down, so check screens in the browser instead.
- What should a startup test first?
A startup should first test the paths that keep or charge a customer: signup, login, the core action and payment. Then add a regression test for each bug a customer reports.