MAI Dev Auditor: A Practical Guide to Reviewing Code Before Release

A project can compile successfully and still contain unclear requirements, risky configuration, or security problems. Before a release or handover, teams need both a clear description of the software and a practical list of issues to investigate. MAI Dev Auditor supports that review by accepting a project ZIP or code file and producing an SRS report plus a separate problems/bugs report, available as Mavorium-branded PDFs.

This guide explains how to prepare an upload, interpret the two reports, and use the findings responsibly across application code, mobile projects, and smart contracts.

Why separate the SRS from the bugs report?

An SRS, or Software Requirements Specification, describes what a system is intended to do. A problems/bugs report addresses a different question: what might be wrong with the implementation? Keeping them separate makes it easier to discuss scope with a project owner without burying developers in a requirements document when they need to investigate an issue.

For an inherited project, use the SRS report as a starting point for confirming your understanding. Compare it with stakeholder expectations and acceptance criteria. Code can reveal implemented behaviour, but it cannot reliably establish every original business requirement. Treat the generated document as something to review, not as proof that the project meets its contract.

Prepare a useful, authorised upload

The live MAI Dev Auditor page supports project ZIPs, archives, or single code files up to 200 MB. It indicates an analysis time of 30–120 seconds and asks users to keep the tab open during processing. Allow time afterward to read and validate the reports; analysis time is not the same as review time.

• Upload only code you own or have permission to share and assess.
• Choose the version you actually plan to release, and record its commit or version identifier separately.
• Include relevant source and configuration files so the review has useful context.
• Remove unnecessary build outputs, dependencies that can be restored, and unrelated archives where practical.
• Remove production credentials, personal data, and secrets before uploading.

Keep an unchanged local copy of the reviewed version. That gives your team a stable reference when investigating findings or comparing later fixes.

Mobile app reviews need source code, not installers

MAI Dev Auditor checks Android Kotlin/Java, iOS Swift, Flutter, and React Native projects and their configurations. The upload should contain source code, not an APK or IPA. This distinction matters when commissioning work: receiving an installable app does not mean you have received the materials needed for a source review.

Before upload, identify the platform, important user flows, and configuration files your team expects to review. Afterward, validate relevant findings on a test device or emulator. A source-level check complements testing; it does not establish that permissions, networking, or authentication behave correctly in every deployed environment.

Smart contract findings require careful verification

For crypto projects, MAI Dev Auditor supports Solidity, Vyper, Rust/Solana, and Move. Its checks include dangers such as reentrancy and owner-drain risks. These are useful areas to investigate because contract behaviour and privileged access can directly affect user funds.

When reading a finding, ask which function is involved, who can call it, and what assets or permissions could be affected. Verify the issue against the actual code and deployment assumptions. A privileged withdrawal function, for example, needs to be evaluated against the intended trust model rather than judged from its name alone.

Automated analysis is not a guarantee that a contract is safe. For systems holding meaningful value, combine it with tests, specialist human review, and deployment controls appropriate to the risk.

Handle exposed keys as an incident, not just a bug

MAI Dev Auditor finds seed phrases or private keys left in code and hides detected secrets before the AI sees them. That protection should not replace your own checks before sharing a project. Do not assume every possible secret will be detected.

If a report identifies a real credential, deleting the line is only one step. Follow your incident process to revoke or rotate affected credentials. For a compromised wallet seed or private key, assess moving assets and permissions to a securely generated replacement. Check repository history and other shared copies as well.

Turn the PDFs into a release checklist

Use the separate reports to create two review tracks: confirm requirements with the project owner, and verify technical findings with developers. Assign each confirmed issue an owner, a priority, and a test that demonstrates the fix. Prioritise exposed credentials, unauthorised access, and potential loss of funds before lower-impact cleanup.

MAI Dev Auditor is a product of Mavorium Private Limited, New Delhi, India. To begin, visit the official MAI Dev Auditor page with an authorised, prepared project. For questions, contact techteam@mavorium.in. The goal is not simply to collect two PDFs, but to turn their findings into documented decisions and verified improvements.