How to Run a Quantum Computing Proof of Concept

A quantum computing proof of concept should answer one narrow question: does a quantum method deserve more testing on a specific business problem?

A useful POC does not promise a transformation. It defines a problem, measures current performance, tests a quantum approach under honest constraints, and produces a decision. The decision might be to continue, pause, or stop.

Start with a business problem, not an algorithm

Do not begin with QAOA, VQE, or a vendor's qubit count. Begin with a decision your team already makes and a measurable cost attached to that decision.

Good starting points include:

• Selecting a fixed number of assets under risk and return constraints.
• Assigning workers, vehicles, or machines to jobs.
• Finding a low-cost route through a defined network.
• Comparing molecular configurations or material candidates.
• Testing a scheduling rule against a known operational workload.

Write the problem in one sentence. Include the inputs, the decision, the constraints, and the metric.

Given input, choose decision subject to constraints and minimize or maximize metric.

A weak POC says, "Explore quantum optimization." A strong POC says, "Reduce schedule cost for this fixed workload while keeping every shift and capacity constraint valid."

Pass three selection tests

A candidate problem needs to pass three tests before a team spends time on hardware.

1. Structure test

The problem should have a structure suited to a known quantum or quantum-inspired method. Combinatorial optimization, molecular simulation, and some sampling tasks fit the usual categories. A generic database, dashboard, or deep-learning workload does not become a quantum problem because a vendor offers access to a QPU.

2. Data test

The team needs stable input data, a repeatable preprocessing path, and a known answer format. Remove confidential fields from early experiments when possible. Record each transformation so a second team reproduces the same instance.

3. Hardware test

Map the real problem to current hardware limits before selecting a provider. Check variable count, qubit connectivity, circuit depth, two-qubit gate count, shot budget, queue time, and access cost. A problem that needs millions of logical qubits is not a near-term POC, even if a small toy version fits on today's processor.

Build the classical baseline first

The baseline is the control group. Run the method your team would use without quantum hardware. Depending on problem size, use an exact solver, a strong heuristic, simulated annealing, a commercial optimizer, or a production rule already used by the business.

Freeze the following before running the quantum version:

• Dataset and train-test split.
• Objective function and constraint definitions.
• Hardware used by the classical solver.
• Time limit and memory limit.
• Random seeds and repeat count.
• Quality and feasibility metrics.

For small instances, solve the problem exactly. An exact answer gives a clean reference for approximation ratio and objective gap. For larger instances, compare against a trusted production method and report its time limit.

Our portfolio optimization business case shows the required shape: exact enumeration, a production-style heuristic, and more than one QAOA formulation on the same data.

Choose the smallest useful instance

A toy problem proves code execution. A useful POC preserves the business structure while staying small enough for careful measurement.

Keep real constraints, realistic distributions, and representative edge cases. Reduce scale only after recording what the reduction removes. A five-variable version of a scheduling problem that drops the shift, capacity, and precedence rules tests a different problem.

Use a ladder:

1. Validate the formulation on a tiny instance with a known optimum.
2. Increase size until the classical baseline shows meaningful work.
3. Test a simulator with ideal and noisy models.
4. Run the same circuit family on real hardware.
5. Repeat across instances and backend conditions.

The goal is not the largest circuit. The goal is a result whose meaning survives contact with the original business problem.

Compare complete methods, not isolated circuits

A fair experiment includes every major step:

• Data loading and preprocessing.
• Problem encoding.
• Circuit construction and transpilation.
• Parameter optimization.
• Sampling and measurement.
• Constraint repair or rejection.
• Result decoding.
• Classical post-processing.

A quantum circuit that finishes in seconds does not create a speedup if classical optimization requires hours or if a queue adds a day. Report circuit time, classical optimization time, queue time, and total wall-clock time separately.

Track metrics that a decision-maker understands:

A single best run is not evidence. Use repeated runs and show spread, failed runs, and parameter sensitivity.

Test simulator results before real hardware

Start with an ideal simulator to catch encoding errors. Then add a noise model to estimate how readout and gate errors affect feasibility and solution quality. Only after both checks pass should the team submit jobs to a QPU.

Use free access where suitable. The IBM Quantum free tier guide explains one route to real hardware, while the simulator comparison covers local options.

Save the transpiled circuit, backend name, calibration date, shot count, mitigation settings, and job identifier. Hardware conditions change. A result without those details is hard to reproduce.

Report the result without marketing language

A POC report should state:

• The business problem and original constraints.
• The baseline method and hardware.
• The quantum formulation and reason for choosing it.
• Instance sizes and data source.
• Circuit depth, gate counts, shots, and repetitions.
• Simulator and QPU results.
• Constraint violations and discarded samples.
• Total runtime and cost.
• Statistical spread and failed runs.
• The next experiment, if one exists.

Separate three claims. "The circuit ran on a QPU" is a hardware fact. "The circuit matched the baseline" is a result for one test set. "The method will outperform production software" is a future claim requiring larger benchmarks.

Our quantum benchmarking guide and QOBLIB coverage explain why shared metrics and classical baselines matter.

Decide whether to continue

Continue when the POC shows a repeatable technical signal and a credible path to a business metric. Examples include better solution quality at a fixed time limit, lower total cost at equal quality, or a hardware requirement aligned with a funded roadmap.

Pause when the formulation works but hardware noise, queue time, or cost blocks a fair comparison. Record the missing capability and define a re-test threshold.

Stop when a strong classical baseline wins across representative instances, when constraints fail too often, or when the proposed quantum method adds no useful information. A clean stop prevents months of unfocused experimentation.

One-page POC template

Use this outline for an internal proposal:

• Problem: one sentence with inputs, decisions, constraints, and metric.
• Baseline: solver, hardware, time limit, and known performance.
• Quantum method: formulation, encoding, and provider.
• Test ladder: ideal simulator, noisy simulator, and QPU.
• Metrics: quality, feasibility, runtime, reliability, and cost.
• Exit rule: numeric condition for continue, pause, or stop.
• Owner: person responsible for data, code, hardware jobs, and report.
• Deadline: date for a decision, not only a demonstration.

A POC earns a second phase by producing evidence about a specific workload. It does not earn one by producing a circuit screenshot or a qubit count.

For broader application context, see what quantum computers do today, companies using quantum computing by industry, and our quantum computing government funding guide.