Read from the ground up.
A software company rests on six layers. Problems in the lower ones, like who owns the code or the cloud account, can stop a deal on their own. We read every layer, rate what we find in plain terms and put a cost on fixing it.
- Layers
- Six, in every review
- Ratings
- Critical, High, Medium, Low
- Access
- Read-only, named, time-limited
- Every finding
- Evidence, impact, cost to fix
What we check.
The same six layers apply to a SaaS product, an online store, a mobile app or an internal system. The engagement changes the depth, not the list.
- 01 · Ownership & IP
- Who controls the code, accounts, domains and licenses, and whether everyone who built the product assigned their work. Typical finding: the production cloud account is registered to a former contractor.
- 02 · Infrastructure & cost
- Hosting, backups and recovery. The monthly bill and what drives it. Typical finding: backups run every night, and nobody has ever tried to restore one.
- 03 · Data & privacy
- Where personal data lives, who can reach it, how long it is kept. Typical finding: customer data copied to a test server without masking.
- 04 · Code & architecture
- Support dates, tests, dependencies and how safely the product can change. Typical finding: the framework is past its end of support, and the upgrade is a project, not a task.
- 05 · Security & access
- Secrets, admin rights, offboarding, vulnerabilities and incidents. Typical finding: one admin password shared by the whole team, including people who left.
- 06 · Team & knowledge
- Who knows what, what is written down, what breaks if one person leaves. Typical finding: one developer holds the only working knowledge of billing.
Does the company own what it sells?
Ownership comes first because a gap here can stop a deal on its own. A buyer pays for code, accounts and data the company controls. If a former contractor holds the cloud account, part of the price rests on something the seller cannot transfer.
- Who is the owner of the root account of the cloud provider, and whose card pays for it.
- Who holds the domain registrar account and the DNS, and when the domains expire.
- Who owns the code repositories, and whether any sit in a personal account.
- Who owns the app store developer accounts and listings.
- Whether every employee and contractor signed an IP assignment, the early ones too.
- Whether agency and offshore contracts transfer the rights to the work.
- A license scan of dependencies for copyleft terms (GPL, AGPL) and how the product uses them.
- Fonts, media and templates used without a license that covers the business.
- Software and API contracts: who signed, assignment, change-of-control clauses.
- Code or accounts shared with another business of the same owner.
- Cloud account in a former contractor's name
- Usually fixable before closing with the contractor's help. Until then it is Critical and a likely closing condition.
- AGPL library inside the hosted product
- Depends on how it is used. Often the fix is one replaced component; sometimes counsel finds no obligation. Counsel gets the facts either way.
What it costs to run, and whether it survives a bad day.
Buyers model the cost of running the product into the price. A cloud bill that doubles with the next customers, or a recovery plan nobody has tested, changes the numbers after closing.
- Where the product runs: providers, regions, accounts and environments.
- The cloud bill over twelve months and the drivers of it.
- Cost per customer, and how it moves as usage grows.
- Long-term commitments to providers that outlive the deal.
- Whether every data store is backed up, and who can delete the copies.
- Whether a restore has been tested from backup, when, and how long it took.
- Whether infrastructure is defined in code or changed by hand in a console.
- Monitoring and alerts: what is watched and who is called.
- Single points of failure: one server, one region, one person with the keys.
- Uptime promises in customer contracts, and whether the system can keep them.
- Nightly backups, never restored
- Usually High. Nobody knows whether the data is safe. A restore test during the review often settles it in a day.
- The cloud bill grows faster than revenue
- Often oversized resources or forgotten environments. It hits the margin the buyer is paying for, so we estimate the bill after the usual fixes.
Where personal data sits, and who can reach it.
Customer data is the asset most likely to bring regulators, contract claims or insurer questions after closing. We map where it is and who can see it, then compare that with what the company tells its customers. Whether a gap breaks a law is for counsel; we give counsel the facts.
- What personal data is collected, in which systems, and why.
- Where it is stored, including backups, logs and analytics tools.
- Retention: how long each kind is kept and whether deletion really happens.
- Subprocessors that receive personal data, and the data processing agreements with them.
- Whether the privacy policy matches what the system does.
- Production data on test servers or laptops, and whether it is masked.
- Whether payment card data ever touches the company's own servers.
- Health, children's or other sensitive data (we flag it; counsel confirms the rules).
- Encryption at rest and in transit, and who holds the keys.
- Past incidents involving personal data, and what was done.
- Unmasked production data on a test server
- Common and usually cheap to fix. It matters because test servers are rarely protected like production.
- A vendor holds personal data with no data processing agreement
- Usually paperwork plus a check of what was shared. It goes to counsel, then into the data room.
Can the product be changed safely?
A buyer usually wants the product to do more after closing. The code decides how fast and at what cost. We do not grade style. We look for what makes change slow, risky or expensive, and read samples line by line where it matters.
- Framework and runtime support dates: end of life, end of security fixes.
- Dependencies: how old, and which carry known vulnerabilities.
- The main components and how they talk to each other.
- Test coverage, what the tests check, and whether they run on every change.
- How changes reach production: review, build, deployment, rollback.
- How often releases go out, and how often one is undone.
- Parts of the code nobody wants to touch, and why.
- What slows down first as data and traffic grow.
- Integrations with payment, ERP or partner systems, and how fragile they are.
- The gap between the product in the pitch deck and the one in the repository.
- Framework past its end of support
- Usually High. Security fixes have stopped and the upgrade takes weeks or months. It belongs in the price or the first-year plan.
- No automated tests around billing
- Every change to how customers are charged is a risk. Typically Medium, with a contained fix.
Who can get in, and who would know.
Security findings move deals as inherited risk and as insurer questions. Underwriters of representations and warranties insurance ask about cybersecurity, and a weak answer can narrow the cover. Most real exposure sits in the basics, so we check them first.
- Secrets in code: passwords, keys and tokens in repositories and their history.
- Multi-factor authentication (MFA) on email, code hosting, cloud and admin tools.
- Offboarding: whether people who left still have accounts or keys.
- Shared accounts and passwords, and how they are stored.
- Who has admin rights, and whether anyone reviews them.
- Known vulnerabilities in the application and its dependencies.
- Past security tests, and whether their findings were closed.
- SOC 2 reports or other attestations: scope and date.
- Whether access to production is logged, and for how long.
- Past incidents, how they were found, and what changed.
- Former staff still have production access
- Cheap to fix and serious until fixed. We also check whether an offboarding process now exists.
- Cloud keys in the repository history
- Rotating them is quick. Whether anyone else used them is the real question, so we read the logs too.
What happens if one person leaves.
In a smaller company the knowledge often sits in two or three heads. A buyer pays for a product that keeps working and changing after closing, so the people matter as much as the code.
- Bus factor: how many people understand each critical part.
- Who made the changes, in which parts, over the last year.
- Documentation, runbooks and onboarding notes, and whether they are current.
- Contractor dependency: agency and freelance work, and the terms behind it.
- Notice periods, and whether a contractor can leave mid-project.
- How knowledge would transfer after closing.
- Who decides on architecture, releases and security.
- Who answers when production fails at night.
- The founder's role in the code, and what changes if the founder steps back.
- The team's own list of what they would fix first.
- One developer holds the only knowledge of billing
- A classic High finding. Usual answers: retention, a written handover, a second engineer trained before closing.
- Most code comes from an agency on a monthly contract
- Fine in itself. A problem when the contract ends on short notice or the IP terms are unclear.
How we rate findings.
Every finding gets one of four ratings, a business impact in plain words, and a cost and time to fix with the assumptions behind them.
Can stop the deal or should be resolved before closing. For example, the company does not control its own code.
Likely to affect price or terms. Needs a plan in the first 90 days after closing.
Raises the cost of owning the product. Belongs in the first-year plan.
Hygiene. Worth fixing when the team is in that part of the system.
How we estimate the cost to fix
Every cost is a range. We estimate the effort in engineer weeks, by the kind of people the work needs, and price it at market rates. Each range states its assumptions: who does the work, the starting point, what must hold for the low end.
We leave out what we cannot price honestly: legal fees, fines, incidents that have not happened, new features. Where a range is wide, we say why. Severity and cost are separate: a Critical finding can be cheap, a Low one expensive.
Read-only, time-limited, closed at the end.
- A non-disclosure agreement is signed before the first document changes hands.
- Access is read-only, through named accounts created by the company, for the period of the review.
- We do not copy personal data. We look at it in place or at masked samples.
- Everything we receive is listed, and the list is part of the report.
- At the end, access is closed, and we confirm in writing what we keep and for how long.
What we never do
We never write to production, change settings or download databases, and we run no penetration test without the company's written consent. We never contact customers, staff or the other side without our client's agreement, and never use what we learn in one review in another. If we see signs of an active breach, we tell our client at once.
Written for the people who decide.
- Summary
- Two pages: the overall view, the findings that affect price or terms, and what we recommend.
- Findings register
- Every finding with layer, severity, evidence, business impact, cost and time to fix.
- Layer by layer
- What we saw in each of the six layers, the strengths as well as the problems.
- Fix plan
- What to do in the first 100 days and the first year, with cost ranges.
- Questions and limits
- Questions for the other side, points for counsel, and what we could not see.
How a finding is written
Each finding stands on its own, so it can be lifted into a board paper or a fix plan: a title that states the fact, layer, severity, evidence with a reference, impact, cost and time with assumptions, and a recommendation. An illustration, fictional and generic:
F-07 · Backups of the main database have never been restored. Layer: Infrastructure & cost. Severity: High. Evidence: nightly snapshots for the last 30 days (cloud console, read-only); the lead engineer confirmed no restore has been tried; no recovery runbook. Impact: recovery time and data loss are unknown, while contracts promise 99.9% availability. Cost to fix: 1 to 2 engineer weeks for a tested restore and a runbook, assuming the current team does it and the snapshots are complete. Recommendation: a restore test before closing or within 30 days after.
From first call to a report you can act on.
Call under NDA
We sign a non-disclosure agreement and talk through the deal, the company and the timing.
Scope and fixed fee
A written proposal: scope, exclusions, the report date, one fixed fee and the people on the review.
Read-only access
Access under the protocol above, a short document request and the interviews.
The report
Summary, findings register, layer-by-layer view and the fix plan.
Walkthrough
We go through the findings with you, your advisors or the other side.
Fixes
If you want issues fixed, our engineering partner PERETZ can do it under a separate contract. Your choice, never a condition.
What we leave to other advisors.
- Legal: contracts, opinions on IP title and privacy compliance. Your counsel.
- Financial: quality of earnings, revenue recognition, working capital. Your accountants.
- Tax: structure, sales tax on software, research credits. Your tax advisor.
- Valuation: what the company is worth. Your banker or valuation firm.
- HR compliance: employment terms, contractor classification, benefits. Your employment counsel.
- Arranging, negotiating or executing the deal. We are not a broker-dealer.
These lines touch ours. A missing IP assignment is a technical fact and a legal question; a cloud bill is a finding and a line in the quality of earnings. We write the fact, mark it for the right advisor and give them the evidence. With your consent we join their calls. We never offer an opinion that belongs to them.
Questions about the method.
Do you use automated scanning tools?
Yes, for dependencies, licenses, known vulnerabilities and secrets in repository history. Tool output is evidence, not a finding: every finding is checked by a person.
Do you read all of the code?
No, and it would not help. We read the structure in full, then line by line where risk sits: billing, sign-in, data access and the parts the team avoids.
Do you run penetration tests?
Not by default. An active test against production needs the company's written consent and is scoped separately when the deal needs one.
What if the seller will not give access to the code?
We review what we are given and say plainly what we could not see. A report with large gaps says so on its first page.
What if the seller's team disagrees with a finding?
We check the evidence again and change the finding if they are right. Otherwise the report shows both views side by side. The severity stays ours.
Is the method the same for a small and a large company?
The layers are the same; depth changes. A red-flag memo reads each layer for deal-level risk, technical due diligence reads them in full.
Do you score or benchmark the company?
No. Scores hide the facts that matter. We compare what we see with what a buyer can expect from a company of that size and stage.
Who checks the work?
Every review is led by a senior engineer and checked by someone with deal-side experience. We name the people before you sign. See about us.
Preparing a sale or looking at a target?
We reply within one business day. NDA before any documents change hands.