Monthly plan
Growth: 8-15 engineers, daily releases, web plus API or one mobile platform
Growth is for 8 to 15 engineers releasing daily, with a web app plus an API or one mobile platform. We test up to 10 releases a week, automate up to 80 flows by month 2, run API contract checks, a mobile release gate, performance smoke on critical flows and LLM-feature regression, and meet you every two weeks. Two environments. $5,900 a month.
Cadence: daily releases. Surfaces: Web, API, one mobile platform. Guarantees apply.
$5,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
- Everything in Starter
- API contract and regression checks
- One mobile platform release gate
- Performance smoke on critical flows
- LLM-feature regression on model or prompt change
- Biweekly call
Not included
- Second mobile platform
- Security regression beyond the checklist scope
- 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
- Daily releases
- Web plus a public API or one mobile app
- An LLM feature in the product
Look at another plan when
- Two mobile platforms (see Scale)
- You need on-call during release windows
- You need security regression beyond checklist items
Week 1
- 01
A named QA lead within 3 business days
- 02
Flow map across web and API or mobile
- 03
Checklist run on the current build including LLM and performance items
- 04
First release verdict within 7 days
- 05
Suite scaffolded in your CI; k6 smoke script for critical flows
The checklist as applied to this plan
v1.0 · verified on 2026-09-21 · 53 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.
LLM features 6
Spend cap enforced per user and globally
automated In a test account, make model calls past the per-user cap and, in staging, past the global daily cap.
Calls beyond either cap are refused with a user-visible message and a log entry; no further provider spend is recorded.
User content cannot trigger tool actions without checks
manual Place instruction text in every user-controlled input the model reads (messages, documents, page titles, retrieved records) and observe tool calls.
No tool action executes from injected instructions; every tool call passes the same authorization as a direct request.
Model output is treated as untrusted before rendering or execution
automated Force outputs containing HTML, script, markdown links and shell-like strings through every render and execution path.
Output renders inert; nothing from the output is executed, evaluated or used as a URL without validation.
System prompt and retrieved context contain no secrets
manual Read the assembled prompt for each feature; run prompt-extraction probes against the feature.
No key, internal URL, other user's data or unpublished business rule is present in the prompt or returned by a probe.
Model or prompt change runs the regression set
automated Maintain a golden set of inputs with expected properties; run it on every model, prompt or temperature change and diff against the recorded baseline.
The golden set runs on the change and the diff is reviewed and signed before release; regressions are listed in the verdict.
Model call failures and timeouts degrade gracefully
automated Inject provider errors, rate limits and 30-second delays.
The user sees a message within the agreed timeout, the request is not retried without bound, and the failure is logged.
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.
Performance smoke 4
Critical flows within agreed budgets under baseline load
tool Run a k6 smoke script over the critical flows at the agreed baseline concurrency against staging.
p95 latency for each flow is within the written budget and the error rate is under 1% of requests in the run.
List endpoints are paginated and bounded
automated Request each list endpoint with no limit parameter and with limit=100000.
Every list endpoint returns at most its documented page size in both cases.
No N+1 query pattern on critical pages
tool Count database queries per request for the ten most visited pages using the ORM's query log.
Query count per request does not grow with the number of rows displayed.
Generated migrations include indexes for new lookups
manual For each new foreign key or filtered column in the release's migrations, check for an index.
Every new foreign key and every column used in a WHERE clause of a critical query has an index or a written reason not to.
Data integrity and migrations 5
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.
Concurrent writes on money and inventory paths are safe
automated Fire 20 parallel requests that spend the same balance or claim the same item.
Exactly the allowed number succeed; the stored balance or stock equals the expected value.
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.
Mobile release gates 5
Purchase flows verified in sandbox on target OS versions
manual Complete each purchase and restore flow with an Apple sandbox account and a Play license tester on the oldest and newest supported OS versions.
Every purchase, restore and failed-payment path ends in the entitlement state the written rules specify on both OS versions.
Permission denial paths are handled
manual Deny each requested permission at the prompt and again permanently; use the feature that needs it.
The app continues with reduced function and explains what is unavailable; no crash or blank screen on any denial.
Supported OS version matrix installed and smoke-tested
tool Install the release build on the minimum and latest supported versions of each platform and run the smoke suite (Appium or Detox).
Smoke suite passes on every cell of the written OS matrix.
Over-the-air updates pass the same release gate
manual Read the OTA update pipeline; confirm the verdict step precedes publish and that a previous update can be republished.
No OTA update can publish without a recorded verdict; rollback by republish was exercised this month.
Subscription renewal, grace period and cancellation tested with accelerated periods
manual Use sandbox accelerated renewals to observe at least three renewals, one failed renewal with grace, and a cancellation.
Entitlement state matches the written rules after each event; the server receives and records each store notification.
What you receive
Every month
- Up to 10 release verdicts a week
- Automated suite toward 80 flows across web, API, one mobile platform
- Performance smoke results against agreed budgets
- LLM regression run on every model or prompt change
- Monthly report by the 5th business day
- Biweekly call
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
QA subscription for SaaS teams
What does a monthly QA report include?
How to test an LLM feature before release?
Email about Growth
The email opens with a short template: team size, release cadence, stacks, AI tools. We reply within 24 hours on business days.