Monthly plan
Starter: 3-8 engineers, weekly releases, web
Starter is for a team of 3 to 8 engineers shipping a web product about weekly, with no QA hire. We test up to 2 releases a week against the published checklist, automate up to 30 critical flows by the end of month 2, and send a monthly report. One named QA lead, one async channel, one environment. $2,900 a month, cancel with 30 days' notice.
Cadence: up to 2 releases per week. Surfaces: Web. Guarantees apply.
$2,900/mo
Termscritical flow (a path a user takes that costs money or trust if it breaks: sign-up, checkout, invite, export) · verdict (a one-word release result (pass, pass with findings, fail) with the findings and the checklist version behind it) · CI (the pipeline that builds and tests every change before it can be merged or deployed) · Playwright (an open-source framework that drives a real browser through your product's flows) · LLM feature (a product feature that calls a large language model, such as an assistant or a summariser) · API (the interface other software calls; tested directly, without the UI in between)
Limits
This plan's limits next to the other two, so the fit is visible before you write.
| Limit | Starter · $2,900/mo | Growth · $5,900/mo | Scale · $9,900/mo |
|---|---|---|---|
| Surfaces | Web | Web, API, one mobile platform | Web, API, iOS, Android |
| Releases per week | 2 | 10 | continuous within scope |
| Flows automated by month 2 | 30 | 80 | 200 |
| Environments | 1 | 2 | 3 |
| Mobile platforms | 0 | 1 | 2 |
| Performance testing | Not included | Smoke on critical flows | Full regression |
| Security testing | Checklist items only | Checklist items only | Regression (no attestation) |
| On-call | Not included | Not included | Planned release windows |
| Calls | Async channel | Biweekly call | Weekly call |
Included and not included
Included
- Release checklist run on every release with a written verdict
- Automated suite for critical flows, maintained by us
- Monthly report
- Named QA lead, async channel
Not included
- API-only or mobile surfaces
- Performance and security regression
- On-call during release windows
Exit terms. Monthly. Cancel with 30 days' notice. No setup fee. The coverage audit fee is credited to the first month of any plan started within 60 days.
Fits when
- One web surface, one environment
- Weekly or twice-weekly releases
- No mobile app, no public API to test
Look at another plan when
- You ship daily or more (see Growth)
- You have a public API or a mobile app
- You need performance or security regression
Week 1
- 01
A named QA lead within 3 business days
- 02
A map of your critical flows
- 03
The checklist run on your current build, findings by severity
- 04
The first release verdict within 7 days
- 05
A Playwright suite scaffolded in your CI
The checklist as applied to this plan
v1.0 · verified on 2026-09-21 · 37 of 53 items run on every release. Full checklist with pass criteria.
Secrets and config 5
No secret keys in client bundles
automated Scan the built client assets (JS, source maps, HTML) for known key prefixes and for every value present in the server environment file.
Zero matches for key prefixes (sk_, service_role, AKIA, whsec_, private keys) and zero server-only env values found in client assets.
No secrets in repository history
tool Run a secret scanner (gitleaks or equivalent) over the full git history, not only the working tree.
Scanner reports zero unrevoked findings; any historical finding has a rotation record.
Public environment prefix carries only public values
manual List every variable with a client-exposed prefix (NEXT_PUBLIC_, EXPO_PUBLIC_, VITE_, REACT_APP_) and confirm each one is meant to be public.
Every client-prefixed variable is documented as public; no variable holds a key that can write or read beyond the anonymous role.
Production runs with production configuration
manual Compare the production environment against a written list: debug flags off, test-mode API keys absent, sample data seeding disabled, verbose logging off.
Every entry on the production configuration list matches; no test-mode key or debug flag is present.
Security headers present on production responses
automated Request the home page, the app shell and one API route in production and read the response headers.
Strict-Transport-Security, X-Content-Type-Options: nosniff and a frame policy (frame-ancestors or X-Frame-Options) are present on every checked response; a CSP is present or its absence is recorded as a finding.
Access control and data isolation 6
Every table exposed to the client has row-level security enabled
automated Query the database catalog for tables in exposed schemas and their RLS flag (Supabase, Postgres) or list collections against rules (Firebase).
Every exposed table reports RLS enabled; the list of exemptions is empty or each exemption is a public read-only table named in the release notes.
Policies deny cross-tenant reads and writes when tested as another user
automated For every table or collection, sign in as user A, create a row, then as user B attempt select, update and delete on it through the client API.
User B receives zero rows on select and a permission error on update and delete, for every table.
Object access checks ownership, not only login
automated For each endpoint or action that takes an id, call it as a logged-in user with an id owned by another user.
Every id-bearing endpoint returns 403 or 404 for a foreign id; none returns the object.
Admin functions are verified on the server
automated Call every admin route and admin server action as a regular user, with and without an admin flag set in the client state or query string.
Every admin route and action rejects the regular user regardless of client-side flags.
The client receives only the fields it renders
manual Inspect API responses and the server-component payload for the five most sensitive screens and list every field returned.
No password hash, token, internal note, other user's email or billing detail appears in any inspected payload.
Firebase rules are out of test mode and covered by rules tests
tool Read the deployed Firestore, Realtime Database and Storage rules; run the rules unit tests in the emulator.
No rule grants read or write to all users without a condition; the rules test suite exists and passes.
Auth and sessions 7
Every protected route verifies the session server-side
automated Request every route marked protected without cookies and with an expired session.
Every protected route returns 401, 403 or a redirect to login; none returns protected content.
Server actions and API mutations re-check authentication and authorization
automated Invoke each server action or mutation endpoint directly by POST, without a session and with another user's session.
Every mutation rejects the unauthenticated call and the foreign-user call.
Auth endpoints cannot be used out of order
manual Call register, verify, reset and invite endpoints out of sequence and with ids or tokens taken from public files.
No endpoint creates a verified account or resets a credential without the intended prior step.
Login and code-entry endpoints are rate-limited with a lockout rule
automated Send 20 failed attempts within 60 seconds to login, OTP and password reset.
Attempts are refused before the 20th, and the refusal is logged with the account or address.
State-changing requests are protected against cross-site request forgery
automated Submit a state-changing request from a page on another origin with the victim's cookies present.
The request is rejected (origin check, SameSite cookie or token) for every tested mutation.
Sessions end on logout and on password change
manual Keep a second browser signed in; log out and change the password in the first; retry a protected request in the second.
The second browser is signed out after both events.
User-supplied content renders inert
automated Submit script, event-handler and URL payloads through every free-text field and view every screen that displays them.
No payload executes on any screen; content displays as text.
Payments and entitlements 5
Webhook signatures are verified against the raw body
automated Send an unsigned event, an event with an altered body, and an event signed with the wrong secret to the webhook endpoint.
All three are rejected with a 4xx status and no state change.
Duplicate and out-of-order events are handled once
automated Deliver the same event id twice and deliver invoice.paid before customer.subscription.created.
Exactly one state change per event id; the out-of-order pair ends in the correct final state.
Plan and entitlement are enforced on the server
automated Call a gated feature with the client-side plan flag edited to a higher tier and with an expired subscription.
The server refuses the gated feature in both cases.
Amounts, prices and quantities originate on the server
automated Alter the amount, currency, price id or quantity in the checkout request.
The altered request is rejected or the server recomputes the amount from its own price table.
Cancellation, downgrade and refund paths update entitlements
manual Trigger cancel, downgrade, failed renewal and refund events in the payment provider's test mode and check the account state.
Each event leaves the account with the entitlement the written rules specify, within one webhook delivery.
Error handling and recovery 5
Failures surface to the user and to logs
automated Force a failure in each critical flow's backing call (database, payment, email, model).
The user sees a specific message and a log entry with a request id exists for every forced failure.
No infinite loading states
automated Block the network mid-request on each critical screen.
Every loading state resolves to an error or retry state within 10 seconds.
Error responses contain no internal detail
automated Trigger 4xx and 5xx responses on API routes and read the bodies.
No stack trace, file path, SQL text or provider error string appears in any response body.
External calls have timeouts and bounded retries
manual Review each outbound call site for a timeout and a retry limit; confirm with a stalled-endpoint test.
Every outbound call has a timeout under 30 seconds and at most 3 retries with backoff, or a documented exception.
Empty results and errors are distinguished
manual Open each list and detail screen with an empty dataset and with a failing backend.
Empty data shows an empty state; a failing backend shows an error state; neither is shown in place of the other.
Data integrity and migrations 4
Migrations are reversible with a tested down path
automated On a staging copy of production data, run the release's migrations up, down and up again.
All three runs complete without error and row counts match before and after.
Destructive changes are gated behind a verified backup
manual For any migration that drops, truncates or rewrites data, confirm a backup taken within 24 hours restores into a scratch database.
The restore completes and a spot check of 10 rows matches production before the change is approved.
Development and production data stores are separate
manual Read the connection configuration for every environment and every tool or agent with database access.
No development, preview or agent environment holds a production connection string.
Cascade deletes are reviewed
manual In staging, delete one parent record of each type and list the rows removed by cascade.
The removed rows match the written deletion policy for that record type.
Deploy and rollback 5
Production deploys are triggered only from the reviewed branch in CI
manual Read the deployment configuration and the last 10 production deploy records.
Every production deploy in the sample originates from CI on the protected branch; no local push or agent session deployed to production.
Rollback rehearsed on the previous release
manual Roll the staging environment back one release, including any data migration, and time it.
Rollback completes within the written target time and the smoke suite passes on the rolled-back build.
Agents and tools hold no write credentials to production
manual Inventory every credential available to coding agents, CI jobs and developer machines.
No agent or developer session credential can write to production data or trigger a production deploy without a human approval step.
Environment configuration matches across staging and production
automated Diff the set of variable names and feature flags between staging and production.
The only differences are values, not names; every flag present in one exists in the other.
Release notes carry the checklist version and verdict
manual Open the release record.
The record names the checklist version, the verdict, the build hash and the tester.
Not in this plan (16 items)
- LM-01 Spend cap enforced per user and globally (growth, scale)
- LM-02 User content cannot trigger tool actions without checks (growth, scale)
- LM-03 Model output is treated as untrusted before rendering or execution (growth, scale)
- LM-04 System prompt and retrieved context contain no secrets (growth, scale)
- LM-05 Model or prompt change runs the regression set (growth, scale)
- LM-06 Model call failures and timeouts degrade gracefully (growth, scale)
- PF-01 Critical flows within agreed budgets under baseline load (growth, scale)
- PF-02 List endpoints are paginated and bounded (growth, scale)
- PF-03 No N+1 query pattern on critical pages (growth, scale)
- PF-04 Generated migrations include indexes for new lookups (growth, scale)
- DM-05 Concurrent writes on money and inventory paths are safe (growth, scale)
- MB-01 Purchase flows verified in sandbox on target OS versions (growth, scale)
- MB-02 Permission denial paths are handled (growth, scale)
- MB-03 Supported OS version matrix installed and smoke-tested (growth, scale)
- MB-04 Over-the-air updates pass the same release gate (growth, scale)
- MB-05 Subscription renewal, grace period and cancellation tested with accelerated periods (growth, scale)
What you receive
Every month
- Up to 2 release verdicts a week, each in writing
- Automated suite maintained and extended toward 30 flows
- Checklist findings tracked to closure
- Monthly report by the 5th business day
- Flaky-test handling with a written cause for each
Every release
A written verdict per release: pass, pass with findings, or fail, with findings listed by severity and the checklist version used.
Escalation. A critical finding reaches your named contact within 4 business hours of us confirming it.
Guarantees, written and shown on every plan
- 01A named QA lead within 3 business days of start
- 02First release verdict within 7 days of onboarding
- 03Every release tested against the published checklist version in force
- 04Monthly report delivered by the 5th business day
- 05If a release ships with a critical finding we marked as passed, the next month is free
Exit terms. Monthly. Cancel with 30 days' notice. No setup fee. The coverage audit fee is credited to the first month of any plan started within 60 days.
What we cannot do
We test against a defined scope and report what we find. We do not guarantee bug-free releases. We do not write your product code. We are not a certified penetration-testing firm and do not issue compliance attestations. Coverage limits per plan are explicit and apply.
Onboarding in four steps
- Day 1
Access and cadence
Read access to the repository, a staging environment, your release cadence, and the named contact on your side. Nothing to install.
- Day 2-3
Flow map and first run
We map the critical user flows, run the checklist against the current build and send the first list of findings by severity.
- Day 4-7
First verdict, suite scaffold
The first release gets a written verdict. The automated suite is scaffolded in your CI, in your repository, under your ownership.
- Week 2 to month 2
Coverage to the plan limit
Automated coverage grows each week and reaches the plan's flow limit by the end of month 2. From week 2 every release runs the checklist and the suite, and the monthly report starts.
Questions
Release testing service for small teams
Fractional QA for startups
How much does managed QA cost?
Email about Starter
The email opens with a short template: team size, release cadence, stacks, AI tools. We reply within 24 hours on business days.