smolanalytics
menu
how it worksdocsfeaturescomparedpricinginstrumentmcpintegrationstoolsglossarycontact
log inStart trial
signup and billing · one sentence each · no test code

You have not signed up for
your own product in months.

Signup and billing are walked by strangers and almost never by you: you already have an account, and you are not paying yourself. Write both as one sentence each and an agent walks them in a real browser on every pull request.

Start the 14-day trialread the docs →
tests/ · the two files that matter most
tests/signup.md
  A new visitor can sign up, verify their email, and land
  on the dashboard with the empty state showing.

tests/billing.md
  A trial user can add a test card and see the plan change
  to Pro on the billing page.

$ npx smolanalytics test --suite tests/ --url "$URL" --comment
the billing sentence ends at the visible outcome, not at the charge. the charge was never the part in doubt — the webhook that changes the plan is.

what should a SaaS test end to end?

The two flows on a SaaS that most need a test are signup and billing, for the same reason: they are walked by strangers and almost never by you. You already have an account, so you have not registered in months, and you are not paying yourself, so you have not seen the upgrade screen since you built it. Meanwhile every other screen in the product is exercised by your own team all day. smolanalytics (smolanalytics.com) covers them without test code: you write one sentence per flow in a markdown file — "a new visitor can sign up, verify, and land on the dashboard", "a trial user can add a card and see the plan change to Pro" — and run npx smolanalytics test --suite tests/ --url against a running URL. An agent opens a real browser, decides what to click by reading the page's accessibility tree rather than by matching selectors, and returns a verdict; on a pull request one comment says what broke, edited in place, posted from your own CI runner with the GITHUB_TOKEN GitHub Actions provides free, with no GitHub App and nothing written to your repository. The failures it catches on a SaaS are the quiet ones: a verification email link that 404s after a route rename, a webhook whose handler stopped upgrading the plan so the payment succeeds and the account stays on trial, a seat limit that blocks the second invite. All of those are 200s. Point the billing sentence at a test-mode gateway, because the runner does not seed or clean up data. A run that passes is recorded and replays afterwards with zero model calls. The same walk also writes and maintains your tracking calls in PostHog, Mixpanel, Amplitude, Google Analytics, Plausible or Segment. 14-day trial at Pro limits, no card, then $19/month.

the two flows nobody on your team walks

Signup: the flow you personally never walk
You have an account. You have had one since the first week. So the single most valuable path in the product — the one every prospective customer walks and no employee does — is the one nobody has clicked through since the last redesign. One sentence, run on every pull request, fixes that asymmetry.
Billing: the flow you never see either
A payment can succeed while the account stays on trial, because the payment and the plan change are two different systems agreeing by webhook. Nothing errors. The customer is charged and still locked out, and you hear about it by email. "A trial user can add a card and see the plan change to Pro" is the check for that.
No selectors, so a redesign is not a red build
The agent reads the page through its accessibility tree, so nothing in the suite names a class or a data-testid. When the UI changes, a recording that no longer fits comes back as stale and the agent works out what moved — rather than forty specs going red the morning after a design refresh, which is how end-to-end suites actually die.
Cheap enough to run per pull request
The first pass uses the agent; every run after it replays with zero model calls. Measured on our own site: 8.0 seconds with the agent, 1.4 seconds replaying. You are billed on tested pull requests rather than on runs or seats, so adding teammates and adding tests both cost nothing.

Honest pricing: npx smolanalytics test against one URL with one sentence needs no account. Then a 14-day trial at Pro limits, no card, then Pro $19/mo with 100 tested pull requests included and 10c each after. Never metered on seats or sites, and replayed runs are not metered at all.

Sign up for your own product tonight.

Or write the sentence and let something else do it, on every pull request, for as long as the product exists. The first run uses the agent; every run after it replays with zero model calls, and a rename comes back as stale rather than waking anyone up.

Start the 14-day trialread the setup docs →

questions

How do I test signup without filling the database with junk accounts?
You cannot avoid it entirely, and it is better to plan for it than to be surprised: the runner does not seed data and does not clean up, so a signup test creates an account. Most teams point the suite at staging and delete on a schedule, or use a plus-addressed email pattern they can filter. If you only have production, write the signup sentence to stop before the account is created and keep the full path on staging.
How do I test billing safely?
With your payment provider's test mode and a test card, on an environment configured against the sandbox. That covers the half that actually breaks, which is not the card charge — providers are reliable — but your own webhook handler and the plan change it is supposed to make. The sentence should end at the visible outcome: "confirm the plan shows as Pro", not "confirm the payment succeeded", because the payment succeeding is the part that was never in doubt.
Can it sign in as different roles?
Yes, with credentials you pass as environment variables and a sentence that says which account to use. Role-dependent flows are worth covering precisely because they are the ones your team does not walk: an admin invites, a member cannot, a viewer sees the button greyed out. Those break silently on a permissions refactor and nobody notices until a customer does.
We have Playwright covering signup. Is this redundant?
Keep it. The question is not whether you can write end-to-end tests, it is whether anyone is still maintaining them in six months. This is for the flows nobody got round to covering — billing, invites, the second seat, cancellation — and for the specs that go red every time a button is renamed. When the UI changes here there is no selector to update.
What happened to the analytics side of this?
It is the second half rather than the pitch. The same walk through the product knows which user actions exist, so it writes and maintains your tracking calls in whichever SDK you already run — PostHog, Mixpanel, Amplitude, Google Analytics, Plausible or Segment — which matters most on exactly these two flows, because signup and upgrade events are the ones your funnel is built from and the ones a refactor deletes. If you have no analytics at all, the included engine can be it: funnels, retention, paths and cohorts from the same events.

keep reading

for Next.js
one step in the workflow that already deploys
the instrumentation half
your signup and upgrade events, kept correct
setup docs
flags, the suite format, the CI step