The issues that matter, in days.
A red-flag memo is a focused read of a software company for the problems that can move the price, change the terms or stop the deal. No long report: what we found, how serious it is and what to ask next.
- For
- Buyers before exclusivity, sellers before going to market
- Timing
- Usually 5 to 10 business days after access
- Fee
- Fixed, agreed before we start
- You get
- A short memo and a call
Early, fast, and before the expensive part.
The memo exists for the moment when a decision is close and the money has not yet been committed: before exclusivity, legal fees and a lender's process, or before a seller's advisor goes to market.
- You are about to sign a letter of intent and want to know if the technology hides a deal breaker.
- You are a search fund or independent sponsor and need a technical read your lender and investors can see.
- You run a buy-and-build program and need a consistent check on smaller add-ons, at their pace.
- You plan to sell in the coming months and want to know what a buyer's reviewers will find first.
- An unsolicited offer arrived, and you want an honest picture before you answer.
- You advise a client and want an independent check before the process starts.
What a memo trades for speed.
A full review reads everything. A memo follows risk. We go first to the places where deal-changing problems usually sit: who controls the code and the accounts, how personal data is handled, what the product is built on and who knows how it works. Elsewhere we sample instead of reading in full, and we check that controls exist instead of testing each one.
That trade is stated in the memo, not hidden. Every memo lists what we read, what we sampled and what we did not examine, so nobody mistakes a fast read for a full one.
Before access: the outside-in read
Early in a process the seller may not grant access yet. We can still read what is public or already shared: the product itself, the website and app store listings, domain and email records, public code, job postings that reveal the stack, the privacy policy and subprocessor list, status page history and whatever sits in the data room. We never scan or test systems we have no permission to touch.
An outside-in read tells you about the stack, the age of the product and the security posture it shows the world. It cannot tell you who owns the code or how the team works. We say plainly which of your questions it answers and which need access.
Red flags, layer by layer.
All six layers, at the depth of risk. These are the kinds of findings a memo is built to catch.
- Ownership & IP
- Who really controls the code, cloud accounts, domains and app store listings. Contractor assignments. Open-source licenses that could create obligations. Typical finding: the main repository sits in a founder's personal account, and an early contractor never signed an IP assignment.
- Infrastructure & cost
- Where it runs, whether backups exist and have ever been restored, and what the bill will look like after the deal. Typical finding: the cloud bill is paid on a personal card, and production runs in one account with no record of how it was built.
- Data & privacy
- Where personal data lives, who can reach it, and obvious gaps against the rules the company is subject to. Typical finding: full copies of the production database on developer laptops.
- Code & architecture
- Frameworks past their end of support, parts nobody can change safely, and how hard the product is to extend. Typical finding: billing has no automated tests, and the team avoids touching it.
- Security & access
- Shared passwords, former staff with access, known vulnerabilities and past incidents. Typical finding: former contractors still hold admin rights, and secrets are visible in the code history.
- Team & knowledge
- Who holds the knowledge, what is written down, and what breaks if one person leaves. Typical finding: one part-time contractor is the only person who knows how to deploy.
Go, go with conditions, or stop and look closer.
The memo opens with one of three views, and the findings behind it.
Go
Nothing we saw should change the price or the structure. There are findings, as in every company, and they belong in the post-closing plan.
Go with conditions
The deal can proceed, but specific findings should be addressed: fixed before closing, priced, or covered in the purchase agreement. We list them as points to raise with your counsel.
Stop and look closer
This is not a recommendation to walk away. It means we found something serious enough that you should not commit more money until it is understood. Typical triggers: the company cannot show it controls its own code or cloud account, personal data is handled in a way that may create legal exposure, or the product depends on a person who is about to leave. The next step is usually a targeted look at that one issue, or a full technical due diligence.
From the first call to the memo.
Scoping call under NDA
We sign an NDA, talk through the deal and the timing, and send a written proposal with one fixed fee and a memo date.
Access and requests
Read-only named accounts and a short request list. If there is no access yet, we start outside-in.
Reading
Code, cloud, documents and one or two short calls with the person who knows the system best.
The memo
Usually 5 to 10 business days after access. A Critical finding is not held for the memo: we call you when we confirm it.
Walkthrough
A call with you and your advisors to go through the findings and the questions for the other side.
- Read-only access to the code repositories and the cloud console, including the billing view.
- A list of third-party services the product depends on, and of contractors who worked on it.
- IP assignment and contractor agreements, or a statement that they do not exist.
- Any system overview, recent security assessment or SOC 2 report, if there is one.
- One hour with the technical lead, and a contact for follow-up questions.
A memo you can read in twenty minutes.
- Summary
- One page: go, go with conditions, or stop and look closer, and why.
- Ranked findings
- Each with severity on our four-level scale, the evidence, the business impact and a rough cost and time to fix with assumptions.
- Next questions
- Questions to put to the other side, and points to raise with your counsel.
- Limits
- What we read, what we sampled and what we could not see.
- Walkthrough
- A call to go through the memo with you and your advisors.
If the memo shows the deal needs a full review, the work already done counts toward a technical due diligence on the same company: we build on it instead of starting again. A seller who receives a memo with months to spare often moves on to vendor due diligence or exit readiness.
Fast, and honest about its limits.
- Not a full review. It finds what can change the deal, not every issue worth fixing.
- Not a penetration test. We check security practice and exposure; we do not attack systems.
- Not a code quality score. We read code to find risk and cost, not to grade the developers.
- Not a valuation, a legal opinion or advice on whether to do the deal.
- Not a promise that nothing else exists. The limits section says what we did not see.
Common questions.
How much access do you need?
Read-only access to the code repositories and the cloud console, the main documents about the system, and a one-hour call with the person who knows it best. We send a short request list after the scoping call, and we keep it short on purpose so the seller can answer within days.
Can it be done without the seller knowing?
Not well. A red-flag memo needs some access to the company. Before access, we can review what is public and what is in the data room, and say clearly what that does and does not tell you. We never probe or scan systems without permission.
Is a red-flag memo enough for a deal?
For a small deal or an early decision it often is. For a larger deal, or when the memo finds serious issues, a full technical due diligence is the safer next step. The memo usually makes it clear which case you are in.
What does stop and look closer mean in practice?
It means one or more findings are serious enough that you should pause before spending more on the deal. It is not a verdict to walk away. Often a targeted check of that single issue, or a document from the seller, resolves it within days.
How fast can you start?
Usually within days of a signed proposal. The clock for the memo starts when access works, so the speed of the seller's answers matters as much as ours. We tell you on day one if anything on the request list is late.
Can a seller order a memo?
Yes. Sellers use it to see what a buyer's reviewers will ask about, before an offer or before going to market. The memo is written the same way for either side. With more time, exit readiness fixes what it finds, and vendor due diligence turns it into a report buyers can read.
Can our lender or investors see the memo?
Yes, if you choose to share it. If a lender or investor needs to rely on it formally, tell us at the scoping call so reliance can be agreed in writing in the engagement letter. If they only need to read it, the terms for sharing are agreed in writing as well, usually in a short letter.
Does the fee count toward a full review?
The work does. If you move on to technical due diligence on the same company, we build on what we already read and the proposal for the full review reflects that. Both fees are fixed and agreed in writing before each piece of work.
Preparing a sale or looking at a target?
We reply within one business day. NDA before any documents change hands.