The Quantum Company Landscape
A hardware startup and a post-quantum security vendor are both "quantum companies," and comparing them on one metric is how diligence goes wrong. This chapter segments the field into layers and gives each layer its own proof gate.
There is no single quantum industry; there are several industries sharing a supply of physics expertise, and a company map that does not separate them cannot rank anyone.
This chapter gives you the working standard: classify companies by what they own — hardware, control, error correction, software, applications, security, sensing, services — then test each claim against the proof gate its category actually sets.
Core concepts: company diligence, startup wedge selection, hardware modalities.
Classification before comparison
"Quantum company" is not a category. A hardware startup, a compiler team, an error-correction group, a sensor maker, a post-quantum security vendor, a cloud platform, and an application company differ in timeline, capital needs, proof gates, and customers. Ranking them on one axis — funding, qubit count, press — compares incomparables.
So diligence starts with classification. What does the company actually own? A qubit modality, a control stack, a developer workflow, a benchmark, an application wedge, a migration tool, a component, a research service? Once the category is fixed, the right proof gate usually becomes obvious — and so does the evidence the company should already have.
Score by category, not by excitement
Expected value still applies, but each category populates it differently:
EV = probability_of_technical_success * value_if_success - cost_of_waiting - cost_of_capital
Hardware plays are capital-hungry with long timelines and large payoffs. Tooling plays are cheaper, nearer, smaller. Security migration sells against an existing deadline. Sensing depends on procurement cycles. The same formula, honestly populated, ranks categories for a given investor far better than excitement does.
The decision score adds the diligence terms:
decision_score = claim_quality + proof_progress - risk - kill_criteria_pressure
— with claim quality measured against what the category demands, not against what the company chose to announce.
Worked example: ten companies, one map
Take ten companies or archetypes and place them: one builds qubits, one builds control electronics, one builds software tooling, one claims application value, one sells security migration, one works on sensing, and so on. A weak map ranks them by buzz. A strong map gives each entry five fields: category, customer, key dependency, proof gate, and failure mode.
The payoff is that proof gates become category-specific. Hardware: device metrics that hold as the system scales. Error correction: logical error rates that fall as the code grows. Tooling: reproducible developer adoption. Applications: a customer pilot that beats a named baseline. Security: migration deployments and interoperability evidence. Sensing: field trials. A company can now be evaluated against the gate its category actually sets — and a company that argues for a different gate has told you something.
How company maps mislead
The first failure is the single ranking metric. Raw qubit counts, funding totals, headcount, patents, and press volume are all context and none are rank. The second is cross-category laundering: a hardware roadmap used to validate an application thesis, or application excitement used to excuse weak hardware evidence. Categories borrow credibility from each other precisely because the map was drawn without boundaries.
Hold the map loosely, too. It is an educational diligence tool for deciding what to study, build, monitor, or investigate next — not an investment recommendation, and not a permanent document. Categories shift as the stack matures; yesterday's component maker becomes tomorrow's acquisition.
The engineering view
This is architecture decomposition applied to a market. Companies occupy layers — hardware, control, compilers, runtimes, applications, security, infrastructure, operations — and a good map shows the dependencies between layers, because dependencies are where risk and leverage live.
It also explains where wedges hide: at interfaces. A developer tool can win without winning the hardware race if it owns the reproducible workflow. A control component creates value before any full processor is useful. A security migration product matters before quantum hardware is cryptographically relevant. Interface positions produce evidence on their own clocks.
Using the map without believing it
For a build decision, pick a narrow layer where your team can produce evidence within months — a benchmark, a tool, a component — rather than a layer where evidence requires someone else's machine. For invest or partner decisions, identify the company's type first and demand the proof gate that type implies; monitor is the right label for categories with high upside and missing proof.
And date everything. Company claims decay faster than any other content in this book, which is why this chapter teaches a method for rebuilding the map rather than a map to memorize.
Exercise
Build the map. Take ten real companies or archetypes.
- Place each in a category and state what it claims to own, in one sentence.
- Write one proof gate and one kill criterion per category — not per company.
- Score one category fully with the expected value and decision score formulas.
- Mark any place where your ranking leaned on press or funding, and redo that entry from evidence.
End by choosing one category and giving it a label — build, partner, invest, monitor, wait, or avoid — in explicitly educational framing. If the map ranks by buzz, the repair is the exercise itself.
Check your understanding
Without notes: sketch the company map and state the main proof gate for each category.
A passing answer separates at least five categories, assigns each a category-appropriate gate, refuses single-metric rankings, and treats the map as a dated artifact to be rebuilt rather than a fact to be cited.
Oral defense: pick the category you would avoid and defend the label against the strongest case for it.
If you get stuck
If your map repeats announcements as evidence, or fails to separate technology proof, market wedge, moat, and timing risk, return to Chapter 72 (When to Build, Partner, Wait, or Avoid) for the decision labels and Chapter 71 (Application Evidence Levels) for the evidence discipline. A company map is those two chapters drawn at market scale.