How the Audit Works
The review runs over two calendar weeks. Each phase has a defined scope and output. Here is what happens from the moment you get in touch through to the final report delivery.
Intake and Scoping
The process begins with a scoping conversation. You describe the app, the platform it runs on, the release you are preparing for, and any areas where you already have concerns. This conversation is not a sales call — it is a technical discussion to confirm that the audit scope is appropriate for your codebase and timeline.
After the conversation, you receive a brief intake document that asks for specific information: the tech stack, the size of the codebase in rough terms, the primary areas of concern, and any known issues you want the review to include. This document shapes the focus of the first week.
Codebase Access and Initial Review
You provide read-only access to the repository. The preferred method is a private repository invite, but other access arrangements can be discussed. No write access is required or requested. The codebase is reviewed in a secure, isolated environment.
The first four days focus on understanding the structure of the codebase before diving into specific areas. This orientation phase produces an internal map of the architecture, the main dependency graph, and the areas that warrant deeper inspection. It also surfaces any immediate, obvious issues that can be noted early.
Deep Analysis Phase
The middle of the review is where the focused analysis happens. Performance-critical code paths are traced and evaluated. Security-sensitive areas — authentication, data storage, API communication, binary analysis — are reviewed in depth. Architecture patterns are assessed against the scale and complexity of the app.
Each area produces a working set of notes that will become findings in the final report. During this phase, there may be one or two short clarifying questions sent to you about specific patterns or decisions — these are not interruptions, just requests for context that would otherwise require assumptions.
Report Writing and Synthesis
Raw notes become structured findings. Each finding is written with a consistent format: location in the codebase, description of the issue, potential impact, severity rating, and a recommended approach. Findings that are connected across different areas — an architectural decision that creates a security exposure, for example — are noted as related.
The report is organized into sections by domain (performance, security, architecture, dependencies, test coverage) and then by severity within each section. A summary section is written last, giving a high-level view of the codebase health and the most important areas to address.
Delivery and Walkthrough
The final report is delivered on day 13. You and your team have time to read through it before the walkthrough session on day 14. The walkthrough is a live call where you can ask questions about any finding, push back on assessments, and discuss the context behind recommendations. This session is not a presentation — it is a conversation.
After the walkthrough, the findings document remains yours. There is no follow-up engagement required, though you are welcome to reach out with questions about specific findings as your team works through remediation.
What to Know Before You Start
Access Requirements
Read-only repository access is sufficient. The review does not require access to production environments, databases, or live user data. If the app interacts with a backend, basic API documentation is helpful but not required.
Your Time Commitment
Your team's involvement during the two weeks is minimal. The intake conversation takes about an hour. There may be one or two short written questions during the review. The walkthrough session is typically 60 to 90 minutes.
Supported Platforms
The audit covers native iOS (Swift, Objective-C), native Android (Kotlin, Java), React Native, and Flutter. Cross-platform codebases targeting both iOS and Android are reviewed with platform-specific considerations for each target.
Report Format
The findings report is delivered as a structured PDF document. It includes a table of contents, a summary section, and detailed findings organized by domain and severity. Findings reference specific files and line numbers where relevant.
Start with a Conversation
The scoping conversation is the first step. Use the contact form to describe your app and your timeline, and we will follow up to arrange a call.