Software code audit: what a founder should get out of one.

You might ask for an audit when the build has stalled and the team's explanations keep changing, when an investor or acquirer is about to look at the code, when a large customer has sent a security questionnaire, or when a new team is about to take over and everyone needs to work from the same facts. Each of those needs a different scope. Say which decision the audit has to support and which parts of the product it covers.

What a useful audit covers

For a launch or takeover decision, comments on coding style do not tell you what works. Agree which of these areas the reviewer will examine and how each observation will be checked:

• Does it run and deploy? Can a new developer set it up from the source, instructions and approved configuration, and is there a repeatable way to release changes?
• Claimed progress versus reality. Which features work end to end with representative synthetic data, and which outcomes remain unverified?
• Data and architecture. Can the database and the overall design carry the users you expect, or will they have to be rebuilt first?
• Security and access. Authentication, permissions, secrets in the code, and whether one customer can see another customer's data.
• Ownership. Who controls the repository, hosting, domain, app store and payment accounts, including recovery access and any transfer constraints.
• The money. What the product costs to run each month, and where revenue or operating value is supposed to come from in the current design.

What you should walk away with

A useful report helps you make a decision. It records the scope, the method, the evidence and the exclusions next to the recommendation. Ask for:

1. A written verdict in plain English: finish it, rebuild parts of it, or stop
2. The reasons and the risks behind that verdict, ranked by how much they matter
3. A list of what is finished and working, and what is not
4. A scoped next step, its assumptions and a way to compare it against the alternatives

How to tell a real audit from a pitch

You can usually tell the two apart by these:

• The scope, billing terms, access and exclusions are agreed before the assessment starts
• You keep the written findings whether or not you hire the auditor afterwards
• The auditor is willing to tell you to stop, or to keep your current team
• Findings are written for you to read, with the engineering jargon explained
• The reviewer states what authorized access is required and what cannot be verified without it

How our Diagnostic works

Our Get It Launched process starts with aDiagnostic: a fixed scope, fixed price review of the code, the product and the money. We read the repository, test what exists, and compare the reported progress with what is there. You get a written verdict you own either way, with the reasons, the risks and a fixed price quote for the defined next step. We list what we could not confirm and what we left out. You do not have to agree to a full replacement to get an assessment.

We also do the build work. You keep the written findings whether or not you hire us for the next phase, and you can use them to compare another team’s proposal. Before any review touches live data, agree which tests will run and the controlled environment they will run in.

Not sure you need one yet? Start with the 12 signs your dev team is failing you or the 2 minute salvageability quiz to prepare your questions. Neither is a technical verdict or a validated failure score. You can also book a free consultation to work out what an assessment needs to answer.