Code Audit Before Investment: What Gets Checked and How to Prepare

A code audit before investment is an independent review of a company’s software, done before money changes hands. It checks whether the code works, whether it is secure and maintainable, and whether the company actually owns and may use what it built. Investors and acquirers run one to price risk. Founders run one first so that nothing in the report surprises them.

This guide covers both sides. It explains what a reviewer looks at, how the work is done, what founders should prepare, how long it takes, and what to do with the findings. It also covers the Swiss legal angle, where ownership and licences matter as much as code quality.

TL;DR

• A code audit before investment tests four things: architecture, code quality, security, and the legal right to use the software (ownership and open-source licences).
• In Switzerland, legal due diligence on software focuses on ownership and licences, while deeper code analysis typically sits in the technical review.
• Founders who audit themselves first control the story: they fix cheap problems and explain expensive ones before an investor finds them.
• Prepare repository access, an architecture overview, a list of dependencies and licences, and proof that every contributor assigned their rights.
• Sort findings into three groups: fix now, fix with investor money, and accept with a plan.

Why investors ask for a code audit

Software is rarely just code. Its value is tied to rights: who owns it, who may copy it, and which third parties could claim part of it. Walder Wyss, a Swiss law firm, describes this link in its technology M&A guide for Switzerland. Understanding the technology tells you which rights should exist. Reviewing licences, ownership, litigation and regulation then tests whether those rights are usable and resilient.

That is why an audit is more than a quality check. An investor wants to know three things:

1. Does it work as claimed? A demo can hide a lot. The codebase shows what is real.
2. Will it survive growth? A product that handles 200 users may fall over at 20,000, and rebuilding it costs money the investor will have to supply.
3. Is it really the company’s? Code written by a freelancer without a rights assignment, or built on a library with a restrictive licence, can reduce what the company owns.

For a founder, the same audit answers a quieter question: how much of the funding will go to fixing the past instead of building the future?

What a code audit examines

A good audit is a health assessment, not a bug hunt. Reviewers look at the system from several angles, and each one maps to a risk an investor cares about.

Architecture and scalability

The reviewer reads how the system is put together: services, databases, hosting, queues, third-party APIs. They ask whether the design fits the product’s stage. A seed-stage product does not need microservices, and a monolith is not a flaw. The red flags are different: a single server nobody can rebuild, a database with no backups tested, or logic spread so thinly that every change touches ten places.

Code quality and maintainability

Here the reviewer samples the code. Is it readable? Are there automated tests, and do they pass? How long does it take a new developer to run the project locally? Code that only its author understands is a business risk, because it ties the company to one person.

Security

Security review covers authentication, access control, secrets handling, input validation, and outdated components with known vulnerabilities. It also looks at how personal data is stored. If you handle customer data in Switzerland, the reviewer will want to see that you thought about the Federal Act on Data Protection, even if the audit itself is not a legal opinion. A security finding rarely kills a deal. Hidden ones discovered late often do.

Dependencies and open-source licences

Modern products are mostly other people’s code. Each library carries a licence, and some licences, known as copyleft, can oblige you to publish your own code if you combine it in certain ways. According to Walder Wyss, Swiss targets customarily provide a precise list of open-source software and applicable licences so that possible copyleft exposure can be identified. Having that list ready is one of the easiest ways to look prepared.

Ownership and intellectual property

The reviewer, or the lawyers working beside them, checks that the company owns what it claims. The same Walder Wyss guide says software due diligence identifies the software the target owns and uses, confirms ownership, reviews licences, and assesses whether it can legally be commercialised. In practice, you need to show who wrote the code: employees, contractors, agencies, or a co-founder who left. Each needs a written agreement that transfers or licenses the rights to the company.

Team and key-person risk

Code audits often include a short conversation with the lead engineer. The question behind it is simple: if this person leaves tomorrow, can someone else carry on? Documentation, deployment scripts and a second person who can ship a release answer it well.

AI-generated code

More teams now use coding assistants. That is fine, but reviewers increasingly ask how much of the code was generated, whether it was reviewed by a human, and whether tests cover it. Unreviewed generated code tends to look tidy and hide duplicated logic or weak error handling. Be ready to say how your team uses these tools.

What the audit does not cover

Set expectations early, because founders sometimes assume the audit is a verdict on the business.

• It is not a legal opinion. Walder Wyss notes that Swiss targets do not customarily provide code scans for legal due diligence, although technical due diligence may involve careful code analysis. Lawyers read contracts and licences; engineers read code. A thorough deal uses both.
• It is not a penetration test. A code review reads the source. A penetration test attacks the running system. Some investors ask for both, and the second is a separate piece of work.
• It is not a market assessment. A beautiful codebase can sit behind a product nobody wants.
• It cannot prove the absence of problems. A reviewer samples. They report what they saw, how deep they looked, and what they did not reach.

How a code audit is carried out

The exact method varies by reviewer, but most follow the same arc.

1. Scoping. You agree on the goal (a seed round, a Series A, an acquisition), the repositories in scope, and the depth. A pre-seed product with one repository needs a different effort than a platform with a dozen services.
2. Access and setup. The reviewer gets read-only access to the repositories, the issue tracker, the deployment configuration and, ideally, a staging environment. Under an NDA, they should never need production credentials.
3. Automated analysis. Tools scan for known vulnerabilities in dependencies, leaked secrets, licence types, test coverage and code complexity. This gives a fast, broad baseline.
4. Manual review. An experienced engineer reads the critical paths: login, payments, data access, the core business logic. Tools cannot judge whether a design makes sense, and this is where most of the real findings come from.
5. Interviews. A conversation with the engineering lead fills the gaps: why decisions were made, what the team already knows is broken, and what is planned.
6. Report and walkthrough. The output is a written report with findings ranked by severity and effort, followed by a call where you can challenge and clarify.

A useful report separates what is wrong from what it costs to fix. Without effort estimates, an investor will guess, and guesses tend to be pessimistic.

How to prepare before the audit

Preparation shortens the review and improves how you look. Spend a week on the following.

Technical material

• Read-only access to all repositories, with a clear README in each.
• A one-page architecture diagram: components, hosting, third-party services, data flows.
• A list of all dependencies and their licences, including build tools.
• Evidence of backups and a tested restore.
• Recent test and deployment results, and a list of known bugs and technical debt.
• A list of who has access to production systems, and how access is removed when someone leaves.

Legal and ownership material

• Employment and contractor agreements showing that rights in the code belong to the company.
• Agreements with any agency or freelancer who built part of the product.
• Records of any code taken from another project or a previous employer. Resolve these before anyone asks.
• Terms for the third-party services your product depends on.

People

• Decide who answers technical questions, and make sure they know the system’s weak points. Investors forgive known problems. They do not forgive denied ones.

If you need a broader view of what buyers and investors examine beyond code, this due diligence checklist for brand owners covers the operating and financial side of investor readiness.

What the audit can uncover: common findings

These are the patterns that come up again and again in early-stage products.

Area	Typical finding	Why an investor cares
Ownership	A contractor built the first version with no rights assignment	The company may not fully own its core product
Licences	A copyleft library is embedded in proprietary code	Possible obligation to disclose source code
Security	Secrets committed to the repository, outdated packages	Breach risk and potential data protection exposure
Architecture	One server, no failover, manual deployment	Downtime and slow delivery as the team grows
Maintainability	No tests, one author, no documentation	Key-person dependency and costly onboarding
Vendor lock-in	Core logic tied to one agency or one proprietary platform	Switching costs and dependency traps

Most of these are fixable. What changes the price of a deal is whether the founder knew about them and had a plan.

How long a code audit takes and what drives the cost

There is no standard price, and quoted figures vary widely between providers and countries, so treat any single number with caution. Four factors drive both duration and cost:

• Size of the codebase. More repositories and more languages mean more reading.
• Depth. A fast automated scan is cheap. A manual review of critical paths plus interviews takes longer.
• Regulation. If you handle payments, health data or other regulated information, expect a deeper security and compliance review.
• Your preparation. Clean access, documentation and a dependency list save days. Hunting for credentials and explanations adds them.

As a rough guide, a focused review of a small product can take days, while a full review of a larger platform takes several weeks. Ask any provider for a fixed scope and a written estimate before they start, and ask what the report will contain. If a deal timeline is tight, say so at the first call so the scope can be set accordingly.

Who should do the audit

Who performs the audit changes how much weight it carries.

• Investor-appointed reviewer. Independent from you, but you do not control the scope or the framing.
• Your own pre-audit. Done by an engineer or studio you choose, before the investor’s team arrives. It gives you time to fix things and prepare answers.
• Your own team. Better than nothing, but investors discount it because it lacks independence.

For most founders, the strongest approach is an independent pre-audit followed by the investor’s own review. When the second review finds what the first already reported, trust goes up.

Choose a reviewer who has built and shipped software, not only audited it. They know which shortcuts are reasonable at your stage and which ones are dangerous. Also check that they have no stake in the outcome, for example, a firm that profits from rebuilding whatever it criticizes.

Fixing findings before investment talks

A report with thirty findings looks frightening. Triage turns it into a plan.

1. Fix now: cheap and visible. Rotate leaked secrets, update vulnerable packages, add the missing rights assignments, write the dependency and licence list, add a README. These take days and remove the easiest objections.
2. Fix with the funding: expensive but explainable. Rewriting an architecture, adding test coverage across the whole product, or migrating hosting. Put a cost and a timeline on each and include them in the use-of-funds plan. An investor who sees a costed plan sees a founder in control.
3. Accept with a plan: low risk or low value. Some debt is rational at your stage. Write down why you are leaving it and when you will revisit it.

Two habits help in the room. First, share the report’s headline findings yourself before the investor asks. Second, never argue with the severity ranking in the meeting; bring a written response afterwards.

If a finding touches ownership, such as a missing assignment from a former contractor, involve a lawyer before you contact that person. That is a legal matter, and the fix is a signed document, not a code change.

How Ampersand can help

Ampersand is a small Zurich studio where senior engineers stay involved from the first conversation to handover. We offer audits and technical due diligence, along with senior-led consulting for founders who need an independent view of their software before a round or a sale. If findings call for work, we can also help with migration, integrations, and ongoing support. See our pricing and engagement options or look at our past work. For reference, our Guidance plan is 799 CHF per month and our Run & monitor support plan is 750 CHF per month.

FAQ

When should I run a code audit before investment?

Run it two to three months before you start fundraising or entering sale talks. That leaves time to fix cheap findings and write a costed plan for the rest. If you are the investor, schedule it after a term sheet or letter of intent and before final commitment.

Who pays for the audit?

It depends on who commissions it. A founder-commissioned pre-audit is paid by the company. An investor or buyer usually pays for their own review, though in some deals the cost is shared or priced into the negotiation. Agree on this at the start, along with who owns the report.

Do I have to give the investor full access to my code?

Not necessarily. A common approach is read-only access under an NDA, often limited to a named reviewer, and sometimes in a controlled environment. Walder Wyss notes that Swiss targets do not customarily provide code scans for legal due diligence, so limits on raw code access are not unusual. A written summary and a licence list are often the first step.

Can a bad audit result stop a deal?

It can, but usually only when problems are hidden, undisclosed or unfixable. Known issues with a clear cost and timeline are normally negotiated: a price adjustment, a condition, or funds reserved for remediation. Ownership gaps and serious licence conflicts are the findings most likely to hold up a closing.

Is a code audit the same as technical due diligence?

No. The code audit is one part of technical due diligence. The wider review also covers team, processes, infrastructure, roadmap and sometimes vendor contracts. The audit gives the evidence behind the technical conclusions.

Sources

• Technology M&A in Switzerland, Walder Wyss
• Due diligence checklist for brand owners