Start with what you can verify without reading code: who owns the repository, the domain and the cloud accounts, whether the product builds from its own instructions, whether backups exist and someone can actually restore from them, and how releases reach production. If that is in order and your doubts are about code quality, security or architecture, you need an independent view: a consultation for a single question, a focused review for one risk area, a full technical audit before growth, a change of contractor or a transaction.
Contents
Why “it works” is not an answer yet
A product that loads and passes a demo can still be expensive to evolve, depend on a single person and store data in a way that cannot be recovered after a failure. The owner sees the interface; these properties live in code, configuration and process. That is why “is the product built well?” is easier to answer as three separate questions.
- Control: do you own the code, the domain, the accounts and the data, and could you keep going if the contractor disappeared tomorrow?
- Maintainability: can you add features without each one costing more than the last and breaking older ones?
- Risk to users and data: what happens if a key leaks, an access rule is wrong, the database fails or a release goes badly?
The owner can settle the first question alone — it is about documents and access. The second and third require reading code and infrastructure, and an internal check is rarely enough even with a technical person on staff: they lack time for a systematic review or were involved in building the product.
What an owner can verify without reading code
These points take one call with the contractor and a couple of hours with your accounts. None of them requires technical training — only access and persistence.
- The code repository sits in your company’s organization or account, you are the owner, and the contractor works with a limited role. GitHub, for example, has roles from
ReadtoAdmin, and full access belongs only to those who truly need it. - The domain is registered to your company, and you hold access to the registrar and DNS.
- Hosting, database, email service, payment provider, analytics and third-party APIs are registered to a company address, not a developer’s personal inbox.
- There is a list of every external service the product uses, who pays for each one and where the access keys are kept.
- A new developer can build and run the product from the instructions in the repository. Ask the contractor to show this on a clean machine during a call.
- Test and production environments are separate: experiments do not happen on the database with real customers.
- Backups run automatically, and you know the date of the last successful restore from a backup — not just the last backup.
- It is clear how a change reaches production and how a bad release is rolled back.
- User-facing errors are recorded somewhere — a log or a monitoring service — and someone actually looks at it.
- Tasks, discussions and demos live in a system you can access, not only in private chats.
If several points fail, that does not condemn the code, but it is a direct business risk: the product effectively belongs to whoever holds the access. Fix these before any audit — they do not require a code review and usually come down to transferring rights and configuration.
Signals that you need an outside view
Code and architecture quality shows up in consequences long before anyone opens the repository. The situations below are where an external review tends to pay off, because an expensive decision depends on its outcome.
- Each new feature takes longer than a similar one six months ago, and the contractor’s estimates regularly miss.
- Releases break things that used to work, and users find out before the team does.
- The contractor cannot clearly explain how part of the system works, or the knowledge sits with one person.
- You are changing contractor or team and want to know what you are handing over and receiving.
- Investment, a sale of the business or a large customer is ahead, and someone will ask about security and reliability.
- There was an incident — a leak, lost data, a long outage — and you need to know whether it was a one-off.
- The product was built quickly, including with AI assistants, and is about to meet real users.
For a conversation about delivery, it helps to lean on the metrics described by the DORA research program. These are not “good/bad” grades but questions a mature team answers with numbers from its own systems.
Change lead time
- Question for the contractor
- How long from a finished code change to it running in production?
- What should worry you
- Nobody knows, or the answer is “depends on when we get round to deploying”
Deployment frequency
- Question for the contractor
- How often do updates ship?
- What should worry you
- Releases are rare and large, each one a risky event
Change fail rate
- Question for the contractor
- What share of releases needed an urgent rollback or hotfix?
- What should worry you
- It is not tracked
Failed deployment recovery time
- Question for the contractor
- How long does recovery from a bad release take?
- What should worry you
- Rollback has never been rehearsed; recovery is manual improvisation
Consultation, focused review or full audit: which to choose
The formats differ in depth and in the question they answer. Getting it wrong costs money either way: a full audit for one question is overkill, and a short consultation says nothing about the system as a whole.
Consultation
- When it fits
- A specific question: should a module be rewritten, is the architecture reasonable, how to judge a contractor’s proposal
- What you get
- Options and risks, a recommendation and a few next steps
- What you won’t get
- Analysis of the whole codebase, guarantees
Focused review
- When it fits
- Risk in one area: access rights, payments, an integration, a specific module
- What you get
- A short report: findings in that area and explicit review boundaries
- What you won’t get
- Conclusions about the system as a whole
Full technical audit
- When it fits
- Before growth, a contractor change, investment or a transaction
- What you get
- An owner summary, evidence-backed findings by domain, priorities and a work plan
- What you won’t get
- Fixes — those are a separate project; a statement that “there are no vulnerabilities”
Penetration test
- When it fits
- You need resistance to attack tested under agreed rules
- What you get
- A specialist report within agreed boundaries
- What you won’t get
- It is a separate service with its own rules of engagement, not part of a regular audit
Separate from one-off checks is code review — routine peer review of changes inside the team. Google’s engineering practices list what a reviewer looks at: design, functionality, complexity, tests, naming, comments, style and documentation. If the contractor’s team has no such process, that alone is a finding: every change reaches the product without a second pair of eyes.
Preparing a review: scope, access, data
Write down the decision and the questions
What you will decide and which questions the report must answer. This sets the depth and keeps the review from sprawling.
Agree on scope
Which repositories, environments, modules and integrations are in, and which are out. Anything out of scope should be marked “not assessed” in the report.
Grant read-only access
Individual and temporary, for a named person. The reviewer does not need to push code or change settings.
Don’t hand over secrets or real customer data
Code, the data schema and a test environment are enough for a review. If data is unavoidable, anonymise it beforehand.
Collect what already exists
A system diagram, a list of integrations, known problems, incident history. Missing documentation is information too; there is no need to hide it.
Tell the current contractor
Their explanations are part of the picture: many decisions look odd without the context in which they were made.
Revoke access when it’s done
Record who had access and until when, and close it once the report is delivered.
What a report must contain — and what it cannot
An audit is valuable when it is verifiable. Each finding should let your team — or any other — reproduce the problem, judge it and confirm the fix. The minimum fields for a finding:
- what exactly was observed and where — component, environment, file or screen;
- evidence: a link to code, a request, a configuration or a screenshot, with secrets and personal data removed;
- business impact in plain words and the likelihood of the problem occurring;
- severity and confidence — how far the fact is proven rather than assumed;
- a recommendation, a rough effort class and retest steps;
- limitations: what might have affected the conclusion.
A useful report
- A one- to two-page owner summary plus technical detail for the team
- Every finding backed by evidence
- States explicitly what was not assessed
- Priorities tied to business consequences
- Any team can work from it
A useless report
- Raw scanner output without analysis
- Verdicts like “the code is bad” with no examples
- Severity inflated to sell fixes
- No scope boundaries — unclear what was left out
- Recommendations like “rewrite everything”
Putting the result to use
An audit report is a tool for a decision, not a verdict on the team. It usually leads to one of three paths: the current contractor fixes findings by priority; the product moves to another team and the report becomes part of the handover; or specific modules are reworked step by step instead of rewriting the whole product. The last option is usually the safer one: the system keeps running and each step carries limited risk.
Good practice is to retest critical findings after they are fixed, using the steps recorded in the report. Then you know not only that the risk existed, but that it is closed.
