12-Point Checklist Before You Sign With a Quantum Computing Vendor

Vendor conversations tend to start in the same place: a number. Forty qubits, a thousand, a million. Someone draws a roadmap on a whiteboard, everyone nods, and the meeting feels productive. Then the contract arrives, and the details that actually decide whether your project succeeds — error rates, queue times, who answers a technical question in week three, and what happens when you want out — are sitting in appendix C.

Buying quantum capacity is not like buying cloud storage. The hardware is still maturing, the vendors are young, and the gap between a press release and a working workload is wide. The checklist below is written for the person who has to justify the spend later.

Start With Your Problem, Not Their Machine

Before any demo, write down the problem you want to attack: a specific optimisation, simulation, or sampling task, with a success criterion you can measure. "Explore quantum advantage" is not a criterion. "Reproduce a known classical result on 20 variables and beat our classical solver's runtime within two years" is.

That framing changes the questions you ask. Instead of "how many qubits?", you ask whether your circuit fits the machine's connectivity, whether the gate error rates let you run enough depth before the result dissolves into noise, and whether the vendor's software stack can express the problem at all.

The 12-Point Checklist

1. Named workload and metric. One problem, one measurable target, agreed in writing before the pilot.
2. Qubit count with context. Ask for physical versus logical qubits, and the connectivity map.
3. Error rates. Two-qubit gate error, single-qubit gate error, and readout error — with the measurement method.
4. Calibration transparency. Are per-qubit calibration logs published? How often does the machine get recalibrated?
5. Circuit depth reality. Coherence times and gate speeds combined: how many useful operations fit in one run?
6. Error mitigation and correction. What works today, and what is only a slide in the roadmap deck?
7. Access model. Shared queue, priority access, dedicated machine, or on-premises — with job limits stated plainly.
8. Software portability. Does your code use open circuit formats, or a proprietary SDK you cannot move?
9. Benchmark evidence. A run of your circuit, with raw data, on a date you can verify.
10. Support commitment. Named technical contact, response times, escalation path, training included.
11. Commercial terms. Minimum commitment, price escalation, auto-renewal notice windows, overage charges.
12. Exit terms. Data deletion, code export, transition assistance, and what happens if the vendor is acquired.

Access Models: What You Are Actually Buying

Most contracts fall into three shapes. Shared cloud access is cheapest and most common: your jobs join a queue alongside other customers, with limits on runtime and shots per job. Priority or dedicated access buys queue position and predictable scheduling, usually at a significant premium. On-premises hardware means you own the operational burden — cryogenics, power, cooling, and a service contract you should read twice.

Ask how priority is enforced when the machine is oversubscribed, what maintenance windows look like, and whether a calibration change can invalidate a job mid-run. If your workload needs low latency to a data centre, ask where the hardware physically sits. A machine two continents away is fine for batch experiments and painful for anything interactive.

Watch the small print on runtime

Queue time is not the same as execution time. A job might wait six hours and then run for forty seconds. If your algorithm needs long circuits or many shots, confirm the maximum runtime per job and whether you can batch submissions.

Benchmarks: Insist on a Proof Run

Vendor demos are chosen by the vendor. Ask instead for a short pilot: you supply the circuit, they supply access and an engineer, and both sides agree on the metric beforehand. Keep it small — one workload, six to eight weeks, a defined end date, and permission for either side to walk away.

Ask for the calibration date attached to the results and the raw measurement data, not just a summary chart. If a claim cannot be reproduced on a second run, that is information worth having before you sign anything long.

Support Is Where Contracts Are Won or Lost

During the sales cycle, send a genuinely hard technical question to the support channel and time the answer. That single test tells you more than any SLA document. Then ask who your named contact would be, whether they are an engineer or a ticket router, and what hours they cover.

• Is training included, and is it live or recorded?
• Is there a documented escalation path with timelines?
• Can you talk to two existing customers of similar size?
• What happens to your access if the vendor changes its hardware generation?

Exit Terms: The Clause Everyone Skips

Quantum vendors consolidate. Some pivot. A contract without exit terms leaves you holding code written against an SDK nobody maintains. Cover the basics: your data deleted on request and confirmed in writing, your circuits exportable in a portable format, a wind-down period with continued access, and transition support priced in advance rather than negotiated in a hurry.

For on-premises systems, go further. Who maintains the dilution refrigerator, who supplies spare parts, and who trains your staff to run it? If the vendor disappears, can a third party service the machine? These questions feel premature while the hardware is still being installed. They feel urgent eighteen months later.

Have a lawyer review the contract, particularly liability, service levels, and termination. The technical team should not be signing away the option to leave.

Run the Evaluation Like a Project

Shortlist two or three vendors, build one weighted scorecard, and score them on the same criteria — workload fit, benchmark results, support responsiveness, terms, and exit. Assign weights before the demos, not after, or the best presenter wins by default. Involve the engineers who will actually run the system; they will spot the integration problems that procurement cannot.

Then set a decision date and honour it. A pilot that drifts for nine months costs more than the contract you were avoiding. Sign small, keep the first term short, and let the results earn the renewal.

Photo: RonaldCandonga / Pixabay