App test audit
Fixed price. Defined scope. Report + bug list. Optional retest. This is the easy yes — and the usual first engagement.
- Agree screens, flows, devices
- Test the build
- Deliver the write-up
- Retest the fixes if you want it
Testing
QA-as-a-service, without the QA department.
For teams that can't justify a full-time QA hire but still ship a native app users depend on. You get a report, a bug list, and a retest after the fix — the coverage an in-house QA function would give you, without the headcount.
Who it's for
Teams with a live native app and no one whose job is QA.
Founders and small teams who can't yet afford a dedicated QA hire. Product managers who need coverage before a store push but have no in-house function to ask. Engineering leads who know native apps break in native ways — permissions, back stacks, restore purchases, process death, dynamic type — and would rather find that out before their users do.
Your app, or an app we built for you — both work. If the app is Flutter or React Native, this isn't the right offer. We don't pretend otherwise.
Coverage
What we actually test on day one.
Starting scope is narrow on purpose. We will not promise a full security audit, load test, or accessibility certification unless that is the engagement we agreed.
- Functional Agreed user journeys, edge states, error paths.
- Regression Previous behaviour after the latest change.
- UI / UX Layout, empty/loading/error, platform conventions.
- Device / OS The matrix we set with you — not “every phone ever made”.
- Performance basics Launch, scroll, obvious stalls. Not a lab benchmark suite.
- Security basics Common mobile mistakes. Not a CREST pentest.
How you buy it
Start with an audit. Stay if the cadence fits.
Price is scoped to screens and flows, not a vague “mobile testing” line. You will know what is in and what is out before we start.
Per-release
Same coverage, repeated on your ship cycle. Useful once the first audit has named the fragile areas.
Each releaseRetainer
Ongoing native QA for teams that ship often enough that one-off audits get stale.
MonthlyDeliverable
A report you can hand to engineering.
Not a slide deck of severity colours with no repro. Each issue has what we did, what happened, where, and why it matters.
Test report
Scope, devices, OS versions, what passed, what failed, what we did not cover.
Bug list
Repro steps, expected vs actual, screenshots or recordings where they help, suggested severity.
Retest notes
After you patch, we mark what is actually fixed — and what still isn’t.
Questions
Straight answers.
Do you build apps as well as test them?
Yes — native iOS and Android app build is a full offer on its own, not a side project. See the build offer. Plenty of clients use only one of the two.
Will you test our Flutter or React Native app?
No. The offer is native only. That is the positioning, not a temporary gap.
Do you need access to our repo or source code?
No. We test the installed build — a TestFlight link or a Play internal-testing / Firebase App Distribution build — the same way your users will experience it. No repo access, no source, no CI credentials. If you can also share the dSYM (iOS) or R8/ProGuard mapping file (Android), that helps us hand back readable crash traces, but it isn't required.
What do you need from us to start?
A build or TestFlight / Play internal track, test accounts, and the flows that matter. If credentials are sensitive, we agree how they are shared before anything is sent.
Is this automated testing?
The audit is expert testing on native platforms. Automation can come later — often as an agent workflow that runs a defined set and reports into Slack or email. See the automation offer — usually a fit once we know the app.
Next
Send the app. We’ll tell you what the audit would cover.
No generic “get a quote”. Tell us the platform, the release, and the flows you care about.