Matching the review to the investment
Technical due diligence (selskapsgjennomgang) verifies the product claim you accepted at the evaluation stage. You decided then that the product exists and works; this workstream checks that it can carry the plan the round is funding, at a depth proportionate to the financial effect of a potential finding.
Consider the review cost in relation to your investment. A founder walkthrough costs you an afternoon and the founders a day of preparation.
A short review by a qualified engineer costs a fee that is small against a lead-sized ticket and large against a round-filling one. A commissioned audit costs a fee that only a lead position, a technology-defined thesis or a product whose value is the code itself will justify.
| Depth | What it finds | What it cannot find | When it fits |
|---|---|---|---|
| Structured founder walkthrough | Whether the system diagram matches the product, whether the team can deploy, whether the accounts and repositories belong to the company, and whether the founders know their own dependencies. | Anything the founders do not know or will not say: hidden debt, a copied component, a security hole. | A round-filling ticket, or any ticket alongside a lead whose technical findings you have read. |
| Short review by a qualified third party | Architecture that will not carry the plan, a deployment process that depends on one person, a dependency inventory that has never been made, and the gap between claimed and measured test coverage. | Defects inside the code, and licence contamination that only a component scan shows. | A lead-sized position on a software company, or a follower with a technical background who takes this workstream for the syndicate. |
| Commissioned audit with code access | Code quality, security defects, a scanned component and licence inventory, and a costed remediation plan. | Whether the product is the right product; that is the commercial workstream’s question. | A lead position where the technology is the thesis, or a hardware-plus-software company whose plan depends on a rebuild. |
In a syndicate, the member with real experience of the domain takes this workstream. The Angel Capital Association’s guidance sets the same condition for group diligence. At least one member should know the field, and that member leads on it.
If nobody in the group can read a system diagram, the syndicate pools the cost of someone who can. Make sure someone in the group can interpret the review and explain what its findings mean for the investment.
Run all five checks at every depth, adjusting the amount of evidence to the scope of the review.
Architecture against the plan
Ask the founders for a one-page diagram of the system as it runs today, showing the components, the data stores, every third-party service, and where customer data sits. A team that has to draw it in the meeting has never had to explain the system to anyone, which tells you how the next engineer will be onboarded.
Ask how the system will need to change to support the plan funded by the round. Ten times the customers, a second market, an enterprise customer with its own security questionnaire: which box on the page breaks first, and has anyone measured where it breaks?
Separate what has run in production from what has run in a demo. A system that has served real users has an uptime history, an incident list and a bill from the hosting provider.
A demo has none of these, however well it performs on the founder’s laptop. Request all three records and reassess the maturity claim if any is missing.
Technical debt and what next year already owes
The way a team delivers changes can reveal technical debt without a code review. Ask the founders for specific answers about each signal.
| Signal | What to ask | What the answer tells you |
|---|---|---|
| Release cadence | When did the last change reach production, and how often does that happen? | A team that ships weekly has a working path to production. A team that last shipped two months ago is either rebuilding or afraid of its own system. |
| Lead time for a change | How long from a decision to fix something until customers have the fix? | Days is healthy at this stage. Weeks means every step is manual, or every change breaks something else. |
| Incident frequency | How many incidents in the last quarter, and what caused the last three? | Repeat causes are debt with a name. A team with no incident list has no way of knowing. |
| Test coverage | How is coverage measured, and what does the number exclude? | A claimed percentage with no tool behind it is an estimate. Ask what is tested by hand before each release. |
| The rewrite list | What would the team rewrite tomorrow if it had a free month? | Every honest team has a list. Its length in months is the part of next year’s roadmap that is already spoken for. |
Convert the rewrite list into months and put it beside the plan. If the plan assumes twelve months of feature development and the team’s own list needs four of them, the milestone the round is meant to reach moves by a third, and that belongs in the timeline before it belongs in the price.
Security and data-protection posture
Grade security on what has been started, because no seed company has finished. Nasjonal sikkerhetsmyndighet publishes basic principles for ICT security in four categories (identify and map, protect and maintain, detect, and handle and recover). NSM states that the principles apply to every organisation and that smaller ones must prioritise among them.
Ask which categories the company has begun addressing, starting with identifying and mapping its systems. A company that cannot list its own systems, devices and user accounts has not begun at all.
The principles are free, official and written for organisations of every size, and there is no audit or certificate against them. ISO 27001 is a paid certification that enterprise customers start asking for later, and a cost that belongs in the plan of any company selling to them.
| Check | What to ask for | Warning sign |
|---|---|---|
| Access control | The list of people with administrator access to production, and the date the last leaver’s access was removed. | A shared administrator login, or a former developer still on the list. |
| Secrets handling | Where passwords, keys and tokens live, and who can read them. | Credentials in the code repository or in a chat thread. |
| Backups | The date of the last backup that was actually restored, and how long the restore took. | Backups that exist and have never been restored. |
| Dependency patching | How the team learns that a component it uses has a published vulnerability, and how long a patch takes to ship. | Nobody owns it. |
| Incident history | Incidents in the last three years, including any breach notified to Datatilsynet or to customers. | An incident the founders describe as “nothing serious” with no record of what was decided. |
The data-protection duties are already law for any company processing personal data (personopplysninger), whatever its size. Under personopplysningsloven, which incorporates the GDPR, the company must keep a record of its processing activities (protokoll over behandlingsaktiviteter), and Datatilsynet states that the exemption for small undertakings will very rarely remove that duty in full.
It must have a data processing agreement (databehandleravtale) with every processor, which for a software company means every hosting, analytics and support tool that touches customer data. Any transfer of personal data out of the EEA needs a transfer basis identified before the transfer, and a transfer to a country covered by an adequacy decision needs no separate one.
A personal-data breach must as a main rule be reported to Datatilsynet within 72 hours, through a form in Altinn that requires a delegated right and an electronic ID, and in stages where the facts are incomplete.
Ask who in the company could file that report today. Check the Altinn access now; discovering that it is missing during an incident can delay the report.
Ask for the four documents and hand them to the legal workstream. The technical review establishes whether they match what the product actually does; whether they are sufficient is a question for counsel.
Third-party and cloud dependencies
List the services the product cannot survive losing, which for most software companies means hosting, payments, identity, e-mail delivery, and any external model or data provider. For each one, ask what breaks if the provider changes its terms, its price or its policy, and what the company would do in the ninety days after that change.
Read the commercial terms of the two or three that matter most. A consumption-priced provider with no committed rate is a cost that scales with success, and a single-region deployment is a dependency on one data centre that the customer contract may not permit.
Pay particular attention to a platform whose policy could threaten the company’s business, such as an app store, a marketplace, or an API the product is a feature of. A founder who has named that risk and priced it has a plan. One who hears it from you for the first time does not.
Assess infrastructure spending per paying customer and ask how it changes if usage grows tenfold.
Key-person risk in the code
Count the people who could ship a fix to production on their own tomorrow. One is the common answer at seed, and it is acceptable only if the founders know it, have written down how the system is deployed, and can say what happens to the roadmap if that person leaves.
Ask who holds the credentials and the accounts: the code repository, the cloud account, the domain registrar, the app-store listing, the signing keys. Each should be owned by the company, with more than one person holding access, and the register of who holds what is a document the company either has or has to write in the session.
Expect the repository and every account to be transferred into the company’s name before closing where they are not already. A repository in a founder’s personal account is a finding for the ownership workstream and a condition of the round.
Source code (kildekode) escrow belongs in customer contracts, where a customer protects itself against a supplier’s failure, and has no place in an angel round at this stage.
Running a proportionate review
Send requests for documents and access before the session so you can spend the time examining the evidence. Record anything not supplied as a finding.
| Request | What it has to show |
|---|---|
| Development history: who wrote which part of the system, when, and under what agreement | The company’s ownership or licence for each contribution is supported by the employment relationship, statute or agreement. Ownership itself is the intellectual-property workstream’s question. |
| Repository access, read-only, or a walk-through on screen | Commit history matching the development history, and a repository owned by the company. |
| Inventory of third-party and open-source components with their licences | An inventory exists, is dated, and was generated from the build rather than from memory. |
| Licences in both directions | What the company has licensed in, and what it has granted out, including any exclusivity. |
| Third-party users of the software, and any source-code deposit made for a customer | Who else holds the code, and on what terms. |
| Domains, app-store listings and brand accounts, with ownership evidence | Registered to the company, with more than one administrator. |
| Data-protection documents: processing record, processor agreements, transfer basis | They exist and match the system diagram. |
| Hosting and administrator access list | Who holds production access, and that the company can revoke it. |
| Breach and incident history, three years | Incidents recorded with what was decided, and any notification made. |
| Employee and contractor assignment confirmations | Written evidence of the applicable transfer or licence, with confirmations where needed. |
Run the session in two hours with the person who deploys the system in the room, and take evidence over assurance at every step. “Show me” produces a fact; “tell me” produces a description.
- A hands-on demonstration in a test account with synthetic or properly anonymised data. Use real personal data only with a lawful basis, necessary scope, appropriate permissions and controlled access.
- The diagram walk-through: the system as drawn, then what the plan does to it.
- The deployment story: the last change that reached production, from the decision to the customer, shown in the tooling.
- The incident story: the last incident, what caused it, what changed afterwards, and where that is written down.
- The dependency and account list: each provider, what breaks without it, who holds the credentials.
Write up one page. For each of the five checks, record what was shown, what was asserted without evidence, and what is missing, then grade each finding as accepted, priced, made a condition of closing, or fatal.
How much of this you run yourself depends on your position in the round.
- A follower reads the lead’s technical findings and verifies the two items that decide your own downside: the account and repository ownership, and whether the system can be deployed by more than one person.
- A lead runs the full session, holds the findings, and decides whether the answers justify paying a reviewer. On a lead-sized position in a software company, the expert review is the default, and a founder who resists read-only repository access has given you a finding.
- A sector angel takes this workstream for the syndicate, spends the session on architecture and dependencies where your judgement is worth most, and asks the questions a generalist cannot test.
Technical findings and what they change
Most of what the review finds is the cost of an early-stage company: thin tests, manual deployments, documentation that lives in one person’s head, a component list assembled for the first time because you asked. Record these, accept them, and put the fixes in the first hundred days.
Some findings require a change in price or timeline. A rebuild the plan did not fund, a dependency whose replacement sits on the critical path, and infrastructure cost that scales faster than revenue each change what the money buys, so the milestone moves or the price does.
Other findings may become closing conditions: company control of accounts and repositories, evidence of IP rights, necessary processor agreements and a component inventory. Confirm the remedy, owner and timetable individually; a missing signature or third-party consent can take longer than the round allows.
A product that cannot perform its claimed core function, or cannot be deployed without a departing person, may end the process. Other findings also need an achievable remedy. Decide which can be accepted, priced or made a condition, and which leave too much uncertainty to invest.