Quantum computing is not automatically the right tool for every difficult problem. This feasibility checklist helps founders, researchers, and innovation teams decide whether a proposed quantum computer use case deserves further investigation, a controlled proof of concept, or a clear no-go decision.
Overview
A credible quantum computing application begins with a well-defined problem, not with a preferred algorithm or a general desire to use quantum technology. The central question is whether the problem has a structure that a quantum method can exploit and whether that potential benefit can survive contact with data preparation, hardware limitations, noise, classical alternatives, and business requirements.
Use the checklist below before committing engineering time or presenting a quantum proof of concept. A promising idea does not need to demonstrate practical quantum advantage immediately. It does need a testable hypothesis, a fair classical baseline, and a path to measuring progress.
A useful screening decision can be expressed in three stages:
- Problem fit: Does the problem map naturally to a known quantum formulation?
- Technical feasibility: Can the proposed method run with available software, hardware, data, and error tolerance?
- Value feasibility: Would an improvement matter enough to justify the additional complexity?
If any stage fails, record the reason rather than forcing the idea forward. A well-documented no-go decision can save more resources than an unfocused prototype.
| Checkpoint | Question to answer | Warning sign |
|---|---|---|
| Problem structure | Can the task be represented as an optimization, simulation, sampling, search, or learning problem? | The quantum formulation is added after the fact and does not match the real workflow. |
| Input size | Is the intended problem large or complex enough to test a meaningful hypothesis? | The example is so small that a classical method solves it instantly. |
| Classical baseline | Which strong, current classical methods will be used for comparison? | The comparison uses a weak, outdated, or poorly configured baseline. |
| Data loading | How will real inputs reach the quantum representation? | Encoding and transfer costs are excluded from the estimate. |
| Algorithm maturity | Is there a documented algorithmic route and an implementation plan? | The proposal depends on an untested promise of exponential improvement. |
| Hardware fit | Can the circuit or simulation fit the available device constraints? | Depth, connectivity, noise, or queue access is treated as an afterthought. |
| Success criteria | What result would count as useful, and how will it be measured? | “Quantum advantage” is the only stated outcome. |
Checklist by scenario
Optimization and scheduling
Optimization proposals often look attractive because many operational problems involve routes, assignments, portfolios, timetables, or resource allocation. Start by writing the objective function and constraints in plain language. Then identify the decision variables, the feasible solution space, and the cost of an imperfect answer.
Ask whether the problem can be represented as a suitable combinatorial model, such as a quadratic unconstrained formulation or another compatible encoding. Check how penalties will represent hard constraints. An encoding that technically includes every constraint may still be impractical if it produces a large, deep, or poorly conditioned circuit.
Compare the proposed method with the solver already used by the organization, not merely with a simple heuristic. Measure solution quality, time to a usable answer, repeatability, and the cost of preparing each instance. For scheduling, also test whether the problem changes frequently enough that model setup and execution overhead dominate any possible improvement.
Simulation of chemistry and materials
Simulation is a natural area for quantum computing because the target systems can have quantum-mechanical structure. That does not make every chemistry or materials project immediately feasible. Define the physical system, the approximation level, the properties to estimate, and the accuracy required by the downstream decision.
Determine whether the project is exploratory or decision-critical. A research team may learn from a small demonstrator even when it cannot yet produce production-grade accuracy. A commercial workflow may require error bars, validation against known results, and a clear comparison with established numerical methods.
Record the chosen representation, circuit depth assumptions, measurement requirements, and expected error sources. If the proposal depends on fault-tolerant resources that are not available to the team, label it as a longer-term research direction rather than a near-term proof of concept.
Machine learning and data analysis
Quantum machine learning proposals require especially careful scrutiny of data movement. Ask where the data originates, how much of it must be encoded, whether the representation preserves useful information, and whether a classical preprocessing step removes the claimed benefit.
Define the task narrowly: classification, regression, generative modeling, dimensionality reduction, or another measurable objective. Establish a classical model with comparable training data, tuning effort, validation rules, and compute accounting. A small dataset can be useful for testing a method, but a small demonstration is not evidence of a scalable advantage by itself.
Sampling, search, and estimation
For sampling or estimation problems, specify the probability distribution, the quantity of interest, the required precision, and the number of samples or circuit executions. Theoretical improvements may be sensitive to assumptions about oracle access, state preparation, or error. Those assumptions must be translated into an implementable workflow.
For search tasks, define what counts as a valid answer and whether verification is cheap. An algorithm that finds candidates quickly may have limited practical value if preparing the search space or checking the outputs is expensive.
Internal research demonstrators
A demonstrator can be worthwhile even without a near-term business advantage. In that case, change the success criteria. Measure whether the team can reproduce results, compare multiple formulations, estimate execution cost, and build knowledge that transfers to later experiments. Treat learning objectives as explicit deliverables rather than implying that every prototype is a product candidate.
What to double-check
Data loading and representation
Many feasibility estimates focus on the circuit while leaving the input pipeline vague. Document the source format, preprocessing, encoding method, state preparation cost, and any classical-to-quantum transfer. If the data must be loaded repeatedly, include that cost for every problem instance. A favorable circuit-level result can disappear when the complete workflow is measured.
Classical comparisons
Use at least one strong baseline and, where practical, more than one method. Match the comparison fairly: use the same input, accuracy target, stopping rule, and output requirements. Include preprocessing, postprocessing, compilation, execution, and verification when those steps are necessary for the quantum workflow.
Do not compare a quantum prototype with an intentionally weak classical implementation. Also avoid comparing unlike quantities, such as a noiseless simulated circuit against wall-clock performance from a fully engineered classical system, without explaining the difference.
Algorithm and software maturity
Identify the algorithm family, required primitives, expected circuit depth, number of measurements, and optimization loop. Then check whether the selected programming framework and backend support the required workflow. A framework comparison can help teams evaluate portability and implementation effort; see the quantum programming frameworks comparison for a structured starting point.
Keep algorithmic assumptions separate from vendor or platform assumptions. A result that depends on one backend, compiler behavior, or undocumented setting may be difficult to reproduce. Record versions, configuration, random seeds where relevant, circuit representations, and measurement conventions. The quantum experiment reproducibility checklist provides a useful companion for this stage.
Hardware and execution constraints
Check qubit count, connectivity, gate support, noise characteristics, circuit depth, calibration dependence, queue or access constraints, and measurement overhead. These are not interchangeable indicators of capability. A device with more qubits may still be a poor fit for a circuit that requires low error or a particular connectivity pattern.
Estimate shots, runtime, retries, and cloud usage before running the experiment. The quantum circuit execution planning guide can help turn an abstract circuit into an execution plan. For broader hardware comparisons, use quality and error measures alongside scale rather than treating qubit count as a complete benchmark.
Measurable value
Write a success statement that a reviewer could evaluate without knowing the project’s hopes. Examples include reaching a target approximation quality within a defined execution budget, reproducing a reference result, reducing the number of evaluations in a controlled setting, or demonstrating a workflow that a classical baseline cannot easily reproduce.
Separate technical advantage from business advantage. A faster computation may not matter if the decision is made only once a year, if the input data arrives slowly, or if a small quality improvement has no economic effect. Conversely, a modest technical result may be valuable as a research milestone if it resolves a significant implementation risk.
Common mistakes
- Starting with the technology: Choosing a quantum algorithm before defining the decision, constraint, or scientific quantity being improved.
- Using toy inputs as final evidence: Treating a small classroom example as proof that the method will scale to operational data.
- Ignoring data movement: Reporting circuit behavior while excluding encoding, transfer, preprocessing, and verification.
- Claiming advantage without a baseline: Using vague language instead of specifying the classical method, metric, and test conditions.
- Confusing simulation with hardware feasibility: Assuming that a circuit that runs in an ideal simulator will produce useful results on an available device.
- Optimizing the wrong metric: Reporting circuit depth or qubit count when the real requirement is solution quality, latency, cost, or reliability.
- Overpromising from a prototype: Presenting a research demonstrator as a deployable product without evidence about scale, repeatability, and integration.
- Failing to define a stop condition: Continuing experiments after the original hypothesis has been disproved or the expected value has become too low.
When to revisit
Revisit the checklist before each planning cycle, whenever the problem definition changes, and whenever the available software or hardware changes. A use case can move from “not yet feasible” to “worth testing” when an algorithm becomes more practical, an execution workflow improves, or the organization gains access to a better-matched backend. The reverse can also happen when a stronger classical method changes the comparison.
Set a review date for every proposal. At that review, update five items: the best classical baseline, the problem size and data distribution, the algorithm and implementation assumptions, the execution estimate, and the success threshold. Keep old results rather than overwriting them so that improvements can be attributed to a changed method, changed hardware, or changed measurement.
Before approving a new proof of concept, require a one-page decision record containing the problem statement, quantum hypothesis, classical baseline, data-loading plan, hardware assumptions, measurable success criteria, expected risks, and stop conditions. Then choose one of three actions:
- Proceed: The problem has a specific hypothesis, a fair comparison, and a feasible experimental path.
- Reframe: The idea is useful for research or learning, but its original performance or commercial claim is too broad.
- Pause: A missing baseline, unrealistic hardware assumption, or weak value case makes further work premature.
This process keeps quantum computing use cases grounded in evidence. It also makes the work easier to explain to technical reviewers, business stakeholders, and future team members who will revisit the decision as the quantum computing landscape develops.
