Mobile App Code Audit
A fixed-scope assessment of what you actually have. Commissioned most often when a developer has gone quiet, when progress has stalled, or before buying a company whose product is an app.
Discuss your projectWhat we examine
Does it build at all
From a clean checkout, on a machine that has never seen the project. The first and most revealing test — an app that only builds on one person's laptop is a business risk whatever else is true.
Version and dependency position
How far behind the framework, language and OS targets are, and whether the libraries it depends on are still maintained. An abandoned dependency is a future rewrite with a date you do not control.
Architecture and data model
Whether the structure supports the features you want next, or whether every change requires touching everything. The data model is the expensive thing to have got wrong.
Security
Where credentials and tokens are stored, whether API keys are hardcoded in the binary, whether traffic is properly secured, and whether access control is enforced on the server or only hidden in the interface.
Tests and release process
What coverage exists, whether it runs automatically, and how a release reaches users. Usually the clearest signal of how the project was actually run.
Store and account position
Whose developer accounts the app sits under, who holds the signing keys, and whether current store policy deadlines are met. Frequently more urgent than any code finding.
What is genuinely finished
Measured against what you were told and what you paid for. This is the section clients read first.
What you get, and how it is written
A written report with findings ranked by consequence and by cost to address, not an unranked list of observations. Each finding states what it is, what happens if it is left, and roughly what fixing it involves. Ranking is what makes a report actionable; an unordered list of forty items gets filed and forgotten.
It is written to be checkable. "Poorly written" is not a finding. "There is no test coverage, and the permission check on the orders endpoint is implemented only in the app, so any authenticated user can read any order by changing an ID" is a finding — specific enough that another developer can verify it and specific enough to argue with.
Where we recommend a rebuild we also state what it would cost to continue with what you have, because carrying on is sometimes the right commercial decision even when it is not the right engineering one. A rebuild is the most profitable thing we could recommend, so you should expect the reasoning in writing and we would encourage a second opinion on it.
When an audit is worth the money
- Your developer has gone quiet and you need to know what you are holding.
- Progress has stalled and you want an independent view before spending more.
- You are changing developer and want the new team to start from facts rather than assurances.
- You are acquiring a company and the app is a material asset — technical due diligence, in effect.
- You are about to commit to a significant new phase and want the foundation checked first.
- An investor or board has asked for an independent technical assessment.
- You suspect you have been overcharged and need a factual account of what was delivered.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch