Case Study 1: Choosing a Framework

"The wrong question is 'which framework is best.' The right question is 'best at what, for whom, measured how, and what does switching cost me in eighteen months.'"

Executive Summary

A computational chemistry group at a mid-sized pharmaceutical company has been given a small budget and eighteen months to answer one question: is there anything here for us? They have two computational chemists who know Python well and no quantum computing experience. They must pick a framework before they can start, and the choice will shape everything that follows.

This case study walks through that decision properly — not as an opinion poll, but as an engineering evaluation with stated criteria, weights, and an explicit accounting of what the decision costs if it turns out wrong. The conclusion the group reaches is probably the one you would guess. The value of the case study is entirely in the method, because you will make some version of this decision, and the ability to defend it to a skeptical director is a professional skill worth more than the answer itself.

Skills applied: the framework survey (§1.2); the software stack and where a framework sits in it (§1.3); the honest capability assessment (§1.5); and the discipline of writing down a success criterion before you have data (§1.7).

Background

The group's situation is worth stating carefully, because framework advice that ignores the situation is worthless.

What they have. Two computational chemists, both fluent in Python and NumPy, both with deep domain knowledge of electronic structure methods and no quantum computing background. Access to a modest classical cluster. A director who is supportive but skeptical and who has read exactly one article about quantum computing, which overclaimed.

What they need to produce. A written assessment, in eighteen months, of whether quantum computing is worth further investment for their molecular simulation work. Not a product. Not a publication, necessarily. An honest internal answer.

What they are not. They are not a quantum computing research group. They will not be developing new algorithms. They will not be buying hardware. They have no budget for significant cloud compute.

The constraint that matters most. Their two people are chemists, not quantum information theorists, and their time is the scarce resource. Anything that costs them weeks of learning that does not advance the assessment is a real loss.

That last point deserves emphasis, because it inverts a lot of framework advice. Much of the discussion online is written by and for people whose job is quantum computing. For a group whose job is chemistry and who are evaluating quantum computing, the calculus is different.

The Criteria

The group's first move — the right one — is to write down what they are optimizing for before looking at any framework. They settle on six criteria with explicit weights.

The weights are arguable and that is fine — the point is that they are stated, so the director can argue with the weights rather than with the conclusion. A recommendation that hides its weights is not a recommendation; it is a preference.

Note what is not on the list: API elegance, performance of the local simulator, and support for frameworks the team might want later. Those are real considerations for other groups. They are not this group's constraints, and including them would dilute the criteria that matter.

The Evaluation

Criterion 1: Free hardware access (25%)

This one is close to decisive on its own.

Qiskit reaches IBM Quantum's free tier, which provides real superconducting processors at no cost. This is the only framework in the survey with genuinely free, generally available access to real quantum hardware. Braket and Azure Quantum (through Q#) both charge per shot on real devices; both have free simulators. Cirq can reach Google hardware only through arrangements not generally available. PennyLane has no hardware of its own but can reach IBM hardware through its Qiskit plugin — which is to say, through Qiskit.

Scores: Qiskit 10, PennyLane 8 (via plugin), Braket 4 (simulators free, hardware paid), Q# 4, Cirq 2.

The group notes something important here that a naive reading would miss: PennyLane's high score on this criterion is inherited from Qiskit. A framework that reaches hardware through another framework's plugin adds a dependency and a failure mode. That does not disqualify it, but it does mean the two are not independent options.

Criterion 2: Chemistry tooling (20%)

The group needs to go from a molecular geometry to a qubit Hamiltonian. Building that pipeline — integrals, second quantization, a fermion-to-qubit mapping — from scratch would consume most of their eighteen months and teach them nothing about quantum computing.

Qiskit Nature does this directly, with drivers into classical chemistry packages and implementations of the Jordan–Wigner and Bravyi–Kitaev mappings. PennyLane has a chemistry module with comparable functionality and a cleaner API for the differentiable-optimization use case. Q# has chemistry libraries, historically strong ones. Cirq has OpenFermion, which is excellent and is in fact where much of this tooling originated. Braket has the least.

Scores: Qiskit 9, PennyLane 9, Cirq 8 (OpenFermion), Q# 7, Braket 4.

This criterion does not separate the leaders. The group flags that explicitly rather than pretending it does — a common failure in evaluations is to manufacture differentiation on criteria where the options are genuinely comparable.

Criterion 3: Community (20%)

Measured concretely: how many questions with accepted answers exist for common problems, how active the issue trackers are, and how quickly a beginner question gets a useful response.

Qiskit is dominant here by a wide margin — the largest user base, the most tutorial material, the most Stack Exchange traffic, and an active dedicated Q&A community. PennyLane has a smaller but notably responsive community with excellent demo material. Cirq has a strong research community that skews expert. Q# has good documentation and a smaller community. Braket has AWS-quality documentation and a modest community.

Scores: Qiskit 10, PennyLane 7, Cirq 6, Q# 6, Braket 5.

The group's reasoning on this criterion is the most important in the evaluation and the least intuitive: for a two-person team with no internal expertise, community size dominates technical merit. A framework that is 20% better designed but has 10% of the answers available will cost them more than it saves. This is uncomfortable for people who like elegant tools. It is also correct.

Criterion 4: Learning curve from Python (15%)

Qiskit, Cirq, PennyLane, and Braket are all Python libraries; a Python-fluent chemist can write a circuit in each within an hour. Q# requires learning a new language with unfamiliar constructs — use scopes, adjoint/controlled functors, within/apply. Q# is a genuinely good language and its concepts are worth learning; that is a different question from whether this particular team should spend three weeks on it.

Scores: Qiskit 9, PennyLane 9, Cirq 8, Braket 8, Q# 5.

Criterion 5: Longevity (10%)

All five have serious institutional backing. The group's realistic concern is not abandonment but API instability, and here the ranking inverts: Qiskit has churned hardest, with the 1.0 removals and the 2.0 Pulse removal. Cirq and PennyLane have been comparatively stable. Q# was substantially redesigned in its modern QDK.

Scores: Braket 8, PennyLane 8, Cirq 8, Q# 7, Qiskit 6.

This is the one criterion where Qiskit scores worst, and the group records it honestly rather than burying it. Their mitigation, recorded in the decision document: pin versions, write down the version each result was produced with, and budget one week of the eighteen months for a migration. That is a real cost, stated in advance, which is exactly the right way to handle a known weakness.

Criterion 6: Exit cost (10%)

If the choice is wrong, what does switching cost?

The group's answer is more optimistic than they expected. A circuit written in any of these frameworks can be exported to OpenQASM and imported elsewhere; the algorithm-level logic (an ansatz structure, a Hamiltonian as a list of Pauli strings, an optimization loop) is framework- independent and portable by hand in a day or two. What does not port is hardware-specific transpilation work and any deep use of a framework's unique features.

Their conclusion: exit cost is moderate and manageable if — and only if — they keep the quantum- specific code isolated behind a thin interface rather than scattering framework calls through the codebase.

Scores: all roughly 7, with PennyLane slightly higher at 8 because its plugin architecture is designed for backend swapping.

The tally

The Decision

Primary: Qiskit. Driven by free hardware access and community size, which together account for 45% of the weight and are the two criteria where this particular team's constraints bind hardest.

Secondary: PennyLane, adopted at the point where the project needs gradient-based optimization — which the group anticipates around month nine, when they move from hand-tuned to optimized ansätze. PennyLane's Qiskit plugin means this is an addition, not a migration.

Explicitly deferred: Cirq, Q#, Braket. With a documented trigger for revisiting each: Cirq if they need to reproduce a specific published result that ships Cirq code; Q# if they need a fault-tolerant resource estimate, which the group correctly identifies as the single most likely question their director will eventually ask; Braket if they need to compare across hardware technologies.

That last provision is the most sophisticated part of the decision. The group has recognized that "which framework" is not a one-time choice but a portfolio decision with triggers, and that the Q# resource estimator answers a question — "how far away is this really?" — that none of the other tools answer well.

Analysis: What Made This a Good Decision

They wrote the criteria before looking at the options. This is the single highest-leverage move. Criteria written after you have a favorite are rationalization, and everyone can tell.

They weighted by their own constraints, not by general merit. A quantum computing research group evaluating the same five frameworks with the same rigor could correctly land on Cirq. The team that tells you their choice is universally correct has not thought about it.

They recorded the loser's advantages. Qiskit scored worst on stability, and that is in the document, with a mitigation and a budgeted cost. A decision document that shows the chosen option winning every category is a document nobody will trust in six months.

They made the exit cost explicit and then acted on it. "Keep quantum-specific code behind a thin interface" is a concrete architectural commitment that follows directly from the exit-cost analysis. This book's running project uses exactly that pattern — Chapter 7 puts every backend behind one interface, and Part III adds four more behind the same interface without changing any calling code.

They set triggers instead of revisiting continuously. "Adopt Q# if we need a resource estimate" is decidable. "Keep an eye on Q#" is not.

Lessons

1. Framework choice is a constraint-satisfaction problem, not a taste question. State your constraints and the answer usually falls out.
2. For a small team without internal expertise, community size beats design quality. This is counterintuitive and it is the finding most often ignored.
3. Free hardware access is worth more than it looks on a spreadsheet when your deliverable is an empirical assessment. A framework you cannot run on real hardware cannot answer the question.
4. Isolate framework-specific code behind an interface from day one. It costs a day and it converts a catastrophic migration into an inconvenient one.
5. The right answer is often "primary plus secondary with a trigger," not a single choice. Most working quantum groups use two frameworks.
6. Write down the version numbers with every result. In a field where a major release deletes core functions, an undated result is an unreproducible one.

Questions

1. Redo the weighted tally for a university research group studying NISQ algorithms, with three PhD students, no chemistry requirement, and a need to reproduce published results. Which criteria change weight, and does the winner change?

2. Redo it for a security team evaluating post-quantum migration risk, whose main deliverable is a resource estimate for breaking their organization's current cryptography. Which framework wins, and why is it a different one?

3. The group weighted "free hardware access" at 25%. Argue for 40% and argue for 10%. Which argument is stronger, and what does that tell you about the robustness of the conclusion?

4. The evaluation gave Qiskit a 6 for longevity, its worst score, and chose it anyway. Under what circumstances would that 6 become disqualifying?

5. PennyLane's hardware access score was inherited from Qiskit through a plugin. Identify one concrete failure mode this creates, and one mitigation.

6. The group deferred Q# with the trigger "if we need a fault-tolerant resource estimate." Write two more triggers, for two other frameworks, that are equally decidable.

7. Hardest. The group's criteria contain no measure of how well a framework teaches its users what is actually happening — its transparency about transpilation, noise, and the gap between the circuit you wrote and the one that ran. Should pedagogical transparency be a criterion for a team whose deliverable is an assessment? Make the case, and propose a weight.