Before paying for code audit services, be clear about the decision you need to make. Can you launch the next version? Can a new team take over? Does a troublesome part need repairing or rebuilding?
A useful audit gives you evidence, business impact and an order of work. It also tells you which parts were reviewed and what remains unknown. That matters whether the code came from your team, a contractor or an AI coding tool.
Use this checklist to compare proposals, understand a sample finding and agree what happens after the review. If you are looking for a provider, see Ekyon's code audit scope and starting price.
What Code Audit Services Should Deliver
Look for three connected outputs:
- An owner summary: the issues that affect the decision you came to make.
- A finding register: what was observed, where, why it matters and how confident the reviewer is.
- A repair plan: priorities, dependencies, likely effort and a way to check the fixes.
A long issue list does not tell you whether to delay launch or schedule work later. Ask the reviewer to explain that distinction. An automated warning may be a useful lead to investigate; its severity is not automatically the severity of a verified problem in your application.
Agree the Decision and Review Boundaries First
A focused audit needs priorities. Before comparing prices, give each provider the same short brief:
| Your decision | Useful review priorities | What to establish upfront |
|---|---|---|
| Launch an MVP | Account access, sensitive data and the main customer journey | Which flows and environments will be reviewed before release |
| Take over an existing app | Architecture, dependencies, deployment and ownership | Which repositories and setup information are available |
| Improve a production system | Reported failures, query patterns and difficult-to-change areas | Whether logs, test data or separately authorised runtime checks are needed |
| Decide whether to rebuild | Structural problems, business constraints and targeted repair options | What evidence would justify a rewrite rather than a smaller change |
Name the repositories, reviewed revision, environments and review time. Ask what the provider will sample and what it will not inspect. Nine hours on selected risks and a deeper multi-repository assessment are different engagements, even if both use the word “audit”.
If you need investor technical due diligence, a penetration test or compliance certification, name that requirement separately. A code review is not automatically any of those services.
The Code Audit Checklist: What to Ask Them to Review
Use these areas to agree coverage. The proposal should identify which checks are included and how they will be carried out.
| Area | Question worth asking | Why a business owner cares |
|---|---|---|
| Access and account boundaries | Are important permissions enforced on the server, including access to another account's records? | Customer data and restricted actions should stay within their intended boundaries. |
| Secrets and data handling | Where are privileged credentials and sensitive records stored, used or exposed? | A working interface can still disclose data or grant unintended access. |
| Important workflows | What happens when a payment, import, export or external service fails or retries? | Partial failures can create missing work, duplicate actions or incorrect records. |
| Architecture and maintainability | Which parts are hard to change, and what documentation is missing? | Your next team needs a realistic route to improving the product. |
| Dependencies | Which versions, known vulnerabilities and relevant licence constraints need attention? | A warning needs context, an affected path and a useful next action. |
| Performance | Is the concern observed or suspected, and under what conditions? | A slow query pattern and a tested production bottleneck need different evidence. |
| Testing | Are the selected critical flows covered, including failure and access-denied cases? | A passing test count alone does not establish that the important behaviour was checked. |
| Deployment and recovery | Who owns configuration, logs, backups and rollback, and what has been verified? | Your team needs to know how to investigate a fault and restore service. |
Not every key visible in a browser is a leaked secret. For example, Supabase distinguishes publishable client keys from privileged secret keys. Ask the reviewer to identify the key type, permissions and actual exposure.
For security coverage, a provider can use selected requirements from OWASP's Application Security Verification Standard as a reference. Ask which requirements and version are included. A reference to OWASP does not mean the entire standard has been verified.
A Sample Finding You Can Actually Use
The following is a hypothetical example, not a finding from a client project or an assessment of your code. It illustrates how evidence and a business decision belong together.
Finding: a signed-in user can request another workspace's export.
| Part of the finding | What a useful report would record |
|---|---|
| Evidence | The reviewed export route checks sign-in but does not check membership of the requested workspace. Record the route, revision and an authorised test showing which records are returned. |
| Business impact | If confirmed, one customer could access another customer's records. State the affected data and reachable accounts. |
| Severity and confidence | Explain urgency using verified exposure and impact. Distinguish a source-code observation from a confirmed runtime finding. |
| Recommended repair | Enforce workspace membership on the server and inspect related export routes. |
| Verification | Test permitted access, denied access and attempts to use another workspace's identifier. |
| Remaining questions | Identify unreviewed routes, inaccessible environments and anything that needs further investigation. |
The repair estimate should include assumptions, an owner and dependencies. A generic “half a day” estimate would leave out investigation, tests, release and any response required if real data was exposed.
Ask to see a sample format before hiring. A provider can show an illustrative report or an authorised, appropriately redacted finding without disclosing another customer's confidential information.
Seven Questions to Ask Before Hiring
- Who reviews the code? Ask who interprets the findings and who joins the walkthrough, as well as which tools support the work.
- What is included in this time budget? Name repositories, priority flows, review depth and exclusions.
- What evidence comes with a finding? Ask for affected areas, reviewed revision, observations and any authorised test results.
- How do you prioritise? Look for business impact, confidence and dependencies, not just a scanner's default severity.
- What is access used for? Agree confidentiality, least-privilege access and any runtime testing before work begins.
- Can my own team use the report? The repair plan should remain useful if another engineer carries it out.
- Who verifies fixes? Establish whether repair work and a follow-up review are separate deliverables.
These answers help you compare an audit proposal on substance. Avoid choosing purely by a promise to scan every file or provide an impressive-looking score.
Code Audit Cost: Compare the Scope Behind the Quote
Ekyon's focused code audit starts at US$1,000, with up to nine hours of review and a one-hour walkthrough within agreed boundaries. Larger or deeper reviews need a separate quote. This is our current offer, not a market-wide “typical audit” price.
Check these items when comparing providers:
- Review coverage: repositories, stack, priority flows and environments.
- Deliverables: owner summary, findings, priorities and walkthrough.
- Access and testing: source review versus separately authorised runtime or load testing.
- Implementation: whether repairs are excluded, included or quoted later.
- Follow-up: what is checked after repairs, by whom and at what cost.
A focused assessment should not claim to establish that every path in a large system is safe. Review time, accessible evidence and the agreed depth all affect what can be concluded.
What to Prepare Before Sharing Your Code
Start with the stack, a short description of the app, the important user journeys and the decision you need to make. Include known problems and relevant deadlines.
Agree confidentiality arrangements and scope before granting access. Use least-privilege repository permissions and an agreed test environment where needed. Do not send passwords, production secrets or customer data in the first enquiry.
Ask how access will be removed after the engagement and how report evidence will be handed over. Any production testing needs explicit authorisation and boundaries; repository access alone does not authorise it.
What Happens After the Audit
Walk through the findings and choose the next action for each: address now, investigate further, schedule later or accept with a recorded reason. The right order depends on confirmed impact and your business decision.
Your existing team can carry out the repairs. If you want the reviewer to implement them, agree a separate scope with acceptance checks and handover. A report should not make a full rewrite the automatic next step.
NIST's Secure Software Development Framework describes practices intended to reduce vulnerabilities and their impact. Treat review and repair as part of that continuing work. An audit is a scoped assessment, not a promise that software will never fail.
Want a review you can turn into a plan?
Tell us what the app does, its stack and the decision you need to make. We will discuss audit fit, priorities and a defined scope.
Frequently Asked Questions
Code audit services assess an agreed software codebase for selected risks such as access controls, sensitive data, important workflows, architecture and deployment. A useful report includes evidence, business impact, review limitations and a prioritised repair plan.
Ekyon's focused audit starts at US$1,000, with up to nine hours of review and a one-hour walkthrough within agreed boundaries. Larger or deeper assessments are quoted separately. This is Ekyon's offer, not a market-wide price estimate.
Only if the proposal explicitly includes them. Ekyon's focused audit covers assessment and a repair plan; implementation and any follow-up verification are separately scoped. Your own team can also carry out the plan.
No. An audit has limits based on scope, available evidence and review depth. It can identify risks and support a decision, but does not guarantee that software has no vulnerabilities or provide automatic compliance certification.
Want a senior review of your codebase?
Ekyon audits AI-built and fast-shipped products for security, architecture, maintainability, and launch risk.
