Application-Company Diligence

Start with the buyer, not the method

Application companies are tempting because they speak the language of customer value. They are risky because many rely on hardware that is not ready, or on benchmarks that do not match customer workflows. Diligence therefore begins with problem choice and baseline, not with the quantum method. The method is the last thing to check, because it is the easiest thing to make sound plausible.

A good application-company memo answers seven questions before it touches the algorithm:

1. Who is the buyer?
2. What is the workflow, end to end?
3. What is the classical baseline — the solver in production today?
4. What data is available, and on what terms?
5. What metric does the buyer actually pay to improve?
6. What quantum resources does the plan assume, and when?
7. What proof gate would justify the next step?

Two scores that keep you honest

The application baseline score is $evidence\_strength-baseline\_gap-integration\_risk-hardware\_risk$. Application companies most often fail because one of the three subtracted terms is larger than the narrative admits — usually all three at once.

Opportunity expected value adds the timing dimension: probability of technical success times value if success, minus the cost of waiting and the cost of capital. The value-if-success term in a quantum application pitch is often genuinely large. That is exactly why the other three terms deserve your attention.

Worked example: the logistics optimizer

A company targets logistics optimization. The weak memo repeats that optimization is valuable and that quantum computers optimize. The strong memo names the buyer, the current solver, the data flow, the constraints, the dollar value per point of improvement, the deployment timeline, and the quantum evidence level. Then it asks the decisive question: can this company create value before fault-tolerant hardware arrives, or is it effectively a long-dated option on that hardware?

The claim, stated precisely: the company owns a problem wedge with a credible quantum or quantum-adjacent path. The proof gate: a customer-relevant benchmark against the real baseline, with integration cost included in the comparison. A benchmark that omits integration cost measures the algorithm and ignores the product.

Where the memo goes wrong

The first trap is accepting "large market plus quantum method" as a company thesis. Large markets attract strong classical competition, and the incumbent solver improves while you wait. The second trap is ignoring data access. A company that cannot get realistic data cannot validate the workflow, no matter how good its methods section reads.

The third trap is breadth. Application companies can go broad too early; a narrow wedge with proof gates is stronger than a platform story with no evidence behind any vertical.

One nuance keeps you from being too harsh: a company whose current product is classical or hybrid may still be worth studying. The diligence question is whether that product creates customer trust, data access, workflow ownership, or domain evidence that compounds if quantum resources improve. A classical product with compounding assets is a better quantum bet than a quantum demo with none.

The engineering view

For a computer scientist, application diligence is product discovery plus benchmark design. You need data schemas, constraints, a baseline implementation, reproducibility, a deployment environment, and monitoring. The quantum component is one module inside a larger workflow.

So the technical memo should contain integration tasks, not only algorithm descriptions. What data must be loaded, and in what shape? What output must be verified, and by whom? How does the customer know the answer is better — which report changes, which decision reverses? If those questions have no answers, the company has a method in search of a product.

What this buys you in diligence

A build decision may favor tools, benchmarks, or domain partnerships before claiming advantage. An invest memo should separate near-term revenue from long-term quantum upside and price each honestly. Avoid is appropriate when there is no strong baseline comparison, no buyer access, and no credible proof gate.

The chapter's discipline also protects you inside a company: the same seven questions are the ones a competent customer's engineering team will ask on the second call.

Exercise

Score one application company. Write an application-company memo with buyer, baseline, technical proof, go-to-market wedge, and kill criteria.

• Submit: the memo, plus the customer-relevant experiment that would change your confidence.
• Check: apply the application baseline score and opportunity expected value. Quote the baseline solver by name and describe its current production use.
• Decide: choose build, partner, invest, monitor, wait, or avoid — and state what evidence would change the label.
• Repair: if your memo starts from the quantum method instead of the buyer's workflow, redo it after Chapter 64.

Check your understanding

Without notes: write an application-company memo with buyer, baseline, technical proof, go-to-market wedge, and kill criteria.

A passing memo names the buyer and the incumbent solver before it mentions qubits, and its proof gate is a benchmark the customer would recognize as their own problem.

Oral defense: take any quantum application press release and deliver, in two minutes, the version of the story told from the buyer's side of the table.

If you get stuck

If your memo lacks source labels, baseline comparison, customer evidence, or kill criteria, revisit Chapter 64 (What Makes a Problem Quantum-Suitable?) for the problem-side test and Chapter 73 (The Quantum Company Landscape) for where application companies sit in the field.