Skip to content

Worked example

One company, two reports.

The same target assessed from both sides of the table: as an acquirer would need it, and as the company should prepare for it. Read them together to see how the same facts look different depending on who has to act.

See the two reportsHow the service works

Read this first

  • This is an internal study, not a client engagement. No client or deal is shown.
  • The sources are a company presentation and additional external research. There was no management access, no data room, no interviews, and no testing.
  • So the reports show how I structure the analysis and what questions I ask. They do not show findings from inside a business, and the company’s own claims remain unverified.
  • The company is not named. “Project Phoenix” is a code name. Nothing here is investment, legal, or technical advice.

The two reports

Same target. Different job.

Each is read on this site, in full, with a confidence rating on every section, a list of what was not tested, and open questions with owners.

Buyer’s view

What an acquirer’s investment committee needs to decide.

Tests the target’s claims, builds the strongest case for and against, checks what engineering and regulation would make of it, and ends in a conditional recommendation with the technical input to price and structure.

Sections

  1. Technology overview
  2. How it works
  3. Preconditions & dependencies
  4. Blue / red team cases
  5. Comparative kill test
  6. Engineering reality check
  7. Build vs. buy
  8. Regulatory & compliance risk
  9. Post-acquisition integration risk
  10. Valuation sensitivity overlay
  11. Overall synthesis
Read the buyer’s view

Seller’s view

What the company should fix before a buyer asks.

Walks the same business the way a buyer’s technical team will: what they will ask, which evidence is thin, and what to prepare, in order, before a process starts.

Sections

  1. Executive summary
  2. Technical architecture overview
  3. Data infrastructure & signals
  4. Ai/ML model assets
  5. Integrations & API strategy
  6. Security & compliance
  7. Technical team & operations
  8. Intellectual property assessment
  9. Customer technical validation
  10. Pre-diligence timeline
  11. Expected buyer technical due diligence questions
  12. Valuation impact analysis
  13. Strategic recommendations
  14. Conclusion
Read the seller’s view

How the two fit

The questions a buyer asks are the fixes a seller makes.

Running both on the same facts shows where a company’s story is strong, and where a buyer will press.

How the buyer’s and seller’s views address the same topics
TopicBuyer asksSeller prepares
The AI claimIs it as differentiated as the deck says? Where would it break?Which claims will be challenged, and what proof exists today?
DependenciesWhat does the product rely on that the target does not control?Which dependencies need documenting or reducing before diligence?
Security and complianceWhat risk transfers to us at close?Which attestations and policies must be ready on day one?
The peopleHow much depends on a few engineers?Who answers technical questions, and are they prepared?
OutcomeProceed, proceed with conditions, or pass.A ranked list of fixes with time to complete each.

The buyer’s view includes a section on how technical findings could bear on price and deal structure. That is technical input to a decision others make. I do not provide valuation, banking, or negotiation services.

A real engagement

A real engagement adds what this study could not.

Access to management and documents, evidence tested against the claims, and the open questions answered, not just listed.

Request scope and availabilityApproach and evidence standard