How it works
Four steps
- Step 1
Share access
Send the app URL and a test login by email. For code review packages, add read access to the repository.
- Step 2
We test
We run the checklist for your package against the live app, by hand and with scripts, inside the turnaround.
- Step 3
Report and call
You receive the findings report and a plain-English summary. We walk you through it if the package includes a call.
- Step 4
Re-check after fixes
Fix with your developer or your AI tool, then we re-test the critical findings within the re-check window, included.
What we test against
Every package is a subset of the same public checklist: the failure catalogue, 54 patterns in ten categories. Each pattern has a self-check you can run before you buy anything.
- Secrets and keys
API keys and passwords the app uses to talk to other services.
- Data access
Rules that decide which user can read or change which rows in the database.
- Login and permissions
How the app knows who you are and what you are allowed to do.
- Payments
Everything between the pay button and the money arriving.
- AI features
Calls to a language model inside the app, and what they can trigger.
- Reliability
Whether the app keeps working when something fails.
- Performance
How the app behaves when there is more data or more users.
- Data integrity
Whether stored data stays correct over time.
- Deploy and config
How code reaches production and how the server is configured.
- Mobile
Risks specific to an app installed on a phone.
What a test looks like from your side
First day. You email. We reply with two or three questions (builder, stack, whether payments or AI features are live) and the package we recommend, with its price. You confirm; payment details arrive by email.
Access. You create a test account for us, ideally two: a normal user and an admin. For repository packages you add a read-only collaborator. We confirm access works and the turnaround clock starts.
Testing. We read the bundle (The JavaScript files your app sends to every visitor's browser.) for keys, call the API (The addresses your app's frontend uses to read and write data.) as a stranger and as each test user, try to reach rows that belong to someone else, replay payment events, and read the configuration that reaches the browser. You may see a handful of test records appear in your database; we label and remove them.
Report. Within the turnaround you receive a PDF and a link. Page one is a summary a non-technical reader can act on. Then a findings table by severity, one page per finding with mechanism, path, what we observed, and a fix direction. The sample report shows the exact format.
Re-check. Fix at your pace inside the re-check window. Tell us when you are ready; we re-test the critical findings and append the result.
Most people start here
Pre-launch check
$490
Report in 48 hours. Re-check included.
Questions about the process
how does an app security test work
You give us a URL and a test login. We work through the checklist for your package: reading the JavaScript your app sends to the browser, calling its API as a signed-in user and as a stranger, trying to reach other users' data, replaying payment events, and reading configuration. Each finding is written up with severity, mechanism, path and a fix direction.
what access do you need to test my app
For outside-in packages: the app URL and one or two test accounts (ideally two roles). For the full audit and test suite build: read-only access to the repository and, where you have one, a staging environment. We never need your production database credentials.
what happens after the report
You fix, with your developer or your AI tool, using the fix direction in the report. Then you tell us, and we re-test the critical findings within the re-check window included in the package. The re-check result is appended to the same report.
do you test the app manually or with tools
Both. Scripts enumerate tables, routes and bundles quickly; a human decides what matters for your app, tries the logic paths a script cannot guess, and writes the report so a non-engineer can act on it.
Not sure which package: run the self-check, or write to us.