Quantum software development

Quantum programs are small. A circuit that fits on today’s hardware might be a few dozen lines. The hard part of quantum software development is everything around it: the classical optimizer that calls the circuit thousands of times, the data that goes in, the tests that tell you whether a noisy answer is right, and the path from a notebook to something your operations team can run on a Tuesday night.

That surrounding code is what we build. We write it so your engineers can read it, test it on simulators, and point it at a different quantum vendor without a rewrite.

What does a hybrid quantum-classical workflow look like?

A hybrid quantum-classical workflow is a loop in which a classical computer prepares the problem, sends short circuits to a quantum processor or simulator, reads back measurements and decides what to try next. Variational algorithms such as QAOA for optimization and VQE for chemistry work this way, as do most quantum machine learning experiments.

Almost every useful quantum program today is built like this. A typical hybrid loop has five parts:

• a problem encoder that turns your data (a routing instance, a portfolio, a molecule) into a circuit or a Hamiltonian
• the circuit itself, parameterized and kept as small as the problem allows
• an execution layer that sends jobs to a simulator or a cloud backend and handles queues, retries and shot budgets
• a classical optimizer or post-processing step
• a comparison against the classical baseline, logged every run

Only the second part is quantum. The other four are ordinary software, and they decide whether the project can be maintained.

Frameworks for quantum software development

We pick the framework for the problem and the hardware, and we don’t hold a strong preference beyond that.

Qiskit, IBM’s open-source SDK, has the largest community and the most direct route to IBM processors. Its 2.0 release removed deprecated 1.x components such as the qiskit.pulse module and BackendV1, which is a good reminder that quantum toolchains still change fast.

NVIDIA’s CUDA-Q is designed for hybrid programs that need GPU-accelerated simulation or sit next to existing HPC code; NVIDIA describes it as one programming model across GPU, CPU and QPU resources. If your team already runs CUDA workloads, it fits naturally.

PennyLane, from Xanadu, treats circuits as differentiable functions and plugs into PyTorch and JAX. It is our usual choice for quantum machine learning and for any experiment where gradients matter.

Cirq, from Google, is common in research code and gives fine control over circuits and device constraints.

Cloud access usually goes through IBM Quantum Platform, Amazon Braket or Azure Quantum, depending on which processors you want to compare.

How do you keep quantum code hardware-agnostic?

Quantum code stays hardware-agnostic when it is split into three layers: a problem definition that knows nothing about quantum hardware, an algorithm layer expressed in circuits or operators, and a backend adapter that is the only place tied to a specific SDK, device or cloud account. Changing vendors then means writing one new adapter.

Vendors will change a lot between now and the end of the decade. IBM plans its fault-tolerant Starling system, running 100 million gates on 200 logical qubits, for 2029, and Quantinuum aims for a universal fault-tolerant machine, Apollo, by 2030. Code welded to one vendor’s current API will age badly. The problem definition holds your data, your objective and your constraints, and the adapter holds the transpiler settings and credentials. Swapping IBM for IonQ, or a GPU simulator for a real device, means writing a new adapter and rerunning the benchmark suite, not rewriting the application.

Where it helps, we use interchange formats such as OpenQASM so circuits can move between toolchains.

How do you test quantum code?

Quantum code is tested at three levels because its results are probabilistic: exact tests on small instances checked against classically computed answers, statistical tests with tolerances that run in CI on every change, and noise tests that use models of the target devices before any paid hardware time is spent.

A test can’t just compare one output to an expected value, so each level checks something different.

1. Exact tests. Small instances run on a state-vector simulator and are checked against answers computed classically. These catch logic errors in the encoding and the circuit.
2. Statistical tests. Larger runs are checked against distributions with tolerances, using enough shots to make a false failure unlikely. These run in CI on every change.
3. Noise tests. We run the same instances with noise models of the target devices, so you know how much of the result survives on real hardware before you pay for hardware time.

Real devices are used sparingly, for calibration runs and final benchmarks. Most of the development budget stays on your own CPUs and GPUs.

Integration with your classical stack and MLOps

The quantum module ships as a normal Python package or container with a documented interface. It gets versioned, logged and monitored like any other model. If you use MLflow, Kubeflow, Airflow or a cloud equivalent, the hybrid job becomes another step in that pipeline, with its parameters, backend, shot count and baseline comparison recorded for every run.

Secrets for cloud quantum accounts stay in your vault. Costs per run are logged, because hardware time adds up quickly on some providers.

The quantum-inspired fallback

For many problems, the honest outcome of a project is that a classical method wins for now. We plan for that from the start.

Every engagement includes a classical baseline, and often a quantum-inspired one: tensor network methods, simulated annealing or parallel tempering on GPUs, or commercial solvers built on those ideas. Quantum-inspired means the algorithm borrows a trick from quantum physics but runs on ordinary hardware. Sometimes it captures most of the gain you were hoping for, and it can go to production immediately.

The quantum module stays in the repository with its tests, ready to be benchmarked again when a new generation of hardware appears. That is a better position than a slide saying “we tried quantum in 2026.”

When this service makes sense

This is a near-term service. It fits after you have a specific problem and some evidence that it has a quantum-friendly structure, usually from use case discovery or a hybrid proof of concept. Without that, you risk building production-quality code for a problem that doesn’t need it.

It also works well when you have engineers who want to own the code afterwards. We pair with them during the build, and the team training can run alongside it.

We are opening engagements in stages. If you have a problem in mind, tell us about it and we’ll tell you whether software work is the right next step or whether something smaller should come first.