Reality > Rhetoric. Customers + revenue = truth.
Following up from my “I’m making a big change” post — I want to give an update. Since we were in our quiet period, I haven’t spoken much…
Reality > Rhetoric. Customers + revenue = truth.
Following up from my “I’m making a big change” post — I want to give an update. Since we were in our quiet period, I haven’t spoken much, but with our Q4 and full 2025 earnings now public — let’s talk.
It’s been AWESOME. The team is growing, and I want to talk to you (go here, search for “field”)
I’m also now immersed in all the hype, buzz, and noise that is in and around the Quantum domain. My X and LinkedIn feeds are distorted. I know I have my bias — but it seems like people might be having the wrong conversations.
I’m trying to keep my head down, focus on expanding the team, working with customers and the product/engineering teams, but I can’t ignore some stuff that’s just flat out wrong.
Let me make this real, and give a customer example.
In early February, I was talking to a customer in Singapore. They are using multiple quantum computer modalities and are literate in this domain. They asked: “We are getting good results and believe in IonQ and the trapped ion modality. But what about all the arguments we hear about ‘gate speed’?”
I’m going to answer this at 3 levels:
- Level 1: Gate speed is the least important parameter, so gate speed is not relevant.
- Level 2 (adds more nuance): Gate speed matters, but much less than many other parameters. In applications built on quantum algorithms (today, tomorrow), in most cases qubit noise/coherence time and the resulting 2-qubit gate fidelity is the bottleneck, and is magnfied by connectivity. This shows up in customer applications (like you’ve found in practice).
- Level 3 (read on for the curious): This takes longer than a sentence. Read on past the break if you want to understand more deeply (and why the level 1 & 2 answer is correct). This will also help one understand why this is really important today, but also is clutch as we leave the NISQ era and move into the scaled Fault-Tolerant Quantum Computing era.
Time to solution (TtS) is the ultimate metric that matters.
There’s a formula for this idea of “time to solution”. In fact, that formula is simple enough that I will eschew my “no formulas” goal:
Time to solution = number of shots to get to needed accuracy x (prep time + time per gate x gates in circuit + readout time).
Think of this as “wall clock speed”, or a stopwatch for the algorithm to run and get to a good answer.
That’s not complicated — but the details matter a lot. Aside: in practice, there are parts of the solution (very commonly these are hybrid workloads) that are outside the quantum algorithm itself, but let’s put those aside for the moment.
Here are some public examples:
First — an example we shared in our Analyst Day (Sept 12th, 2025) and explain it in human terms (and then give another example hot off the presses).

The one on the left is an optimization problem (QAOA, variants of which are used in many industry use cases). Each point is a set of results from many shots (5000) through a set of systems (IonQ and some examples of superconducting modalities including IBM, IQM, Rigetti) As soon as the problem got more “rich” (“n” and “p” got larger) the circuits got deeper. The Y axis is “approximation ratio”. If you drop below a floor (shown here as the grey horizontal line), the answers you are getting are not useful. The grey line is roughly the results you would get from a random coin flip, so.. shall we say “not great”?
Look at the graph — it shows that even at these relatively small problems, low-gate speed systems may be fast… but are fast at generating results that are not useful.
If you wanted to get better results from the other systems, you could run many more shots (making Time to Solution higher) — but at a certain point, you’re below the noise floor. You can’t get anything useful from the results no matter how many shots.
BTW — I called out the QAOA example, but it was similar with QFT and FAA algorithms.
Here’s another example used in our earnings call at the end of Feb 2026 that I’ll double-click on:

This is a quantum fourier transform (QFT) algorithm. The QFT algorithm is widely used in other algorithms (some search algorithms, Shor’s algorithm for factoring numbers, and use in GNNs for use cases like pattern/object recognition). Unlike the previous graphs, we put accurancy on the x-axis, and the TtS on the Y-axis. With GFT “accuracy” translates to “Hamming Distance from nearest target” which means “how close are you to finding the repeating period/string/vector you’re looking for” (where 0 = you’ve exactly got it).
You can see that superconducting systems (and this is the state of the art system we’re comparing against) are faster if you are ok with not finding what you’re looking for.
The crossover point is where you still are pretty far from the needle in the haystack, there TtS looks “close” if you’re ok with a not-so-good answers (Hamming Distance of 16).
But, if you actually care about the correctness of the answer, the divergence gets stark.
If you want a good answer (closer to 0) the IonQ system has a time to solution that is 1000x faster.
It’s also notable that the TtS with IonQ is pretty consistent, only rising roughly 1–2 orders of magnitude when you need extreme accuracy (and more shots).
Conversely, the superconducting system has a range that swings by 8 orders of magnitude. That’s a 100,000,000x swing. The dotted line on the blue line as we move to accurate results is that we needed to do a million shots or more, and started to just get nowhere — so using a random sampler was actually faster (so no one would practically do it on the superconducting system). Interestingly if you look at a histogram of all the shots, the superconducting system has a bell curve shaped distribution — only slightly shifted to the answer. It’s a coin flipper with only a slight bias.
Why is this the case? With the superconducting systems with higher noise, lower 2-qubit gate fidelity, poor qubit connectivity (the QFT circuit when transpiled to run on the hardware needs to do more “touches” to each qubit particularly for 2-qubit gates) you need so many shots, it’s not useful, and the TtS just grows and grows.
Ultimately (and over time) — the market speaks. Customers at large (not one here or there) and market performance over time are the things that reveal reality. I’m more confident in my choice every day — and look forward to sharing more regularly.
Now this all hints towards deeper understanding, and we’re all getting a little smarter.

As you start to understand this domain — here are a next set of questions that flow from a “deeper level 3 understanding”:
- Q: The logical code (Qiskit, for example) — how does it transpile down to actual execution on the hardware? Depending on many factors (like qubit connectivity, native gate support, parallel gates) there can be huge overheads that don’t show up until you actually run the app. In practice, this is huge, and as circuits get deeper and deeper, this just gets more and more important. The overhead can easily be 10x or more, in particular for superconducting qubit systems where each 2-qubit can can generate a number of extra gates in the compilation that scales with the overall system size, easily exceeding a 10x or even 20x overhead. And that is per each gate.
- Q: Are you able to complete the circuit at all? Or do you run out of coherence time budget (which is a function of gate speed, number of gates, fidelity and coherence time)? Again, note that this is not about the complexity of the algorithm directly, but ultimately how it gets compiled/transpiled to run on actual hardware. There are exciting quatum computing startups that create qubits and gates but can’t actually run an algorithm. That’s not useful.
- Q: If you complete the circuit do you generate such noisy results that they are NOT functionally useful? Or put another way: do you need a huge number of shots to try to get a signal from the noise if you are able to EVER get to the accuracy you need? Sometimes the answer is you hit a noise floor (the quantum system decoheres) and can never get to an answer with more shots.
- Q: Does this change as we are currently moving into the era of Fault Tolerant Quantum Computer (FTQC) error corrected systems?
I’ll answer #4 with a pointed and direct answer: A: NO.
These set of parameters (noise, the importance of 2 qubit gate fidelity, universal gate support, qubit connectivity, parallelism, etc) doesn’t go away as we move to fault tolerant, quantum error corrected (QEC) systems.
In fact, it becomes MORE important (because QEC is itself “an algorithm under the algorithm”).
Q: Why? A: All these fundamental properties get “magnified” by the system architecture many, many times over in error corrected systems and get exponential. This is further multiplied as we move to deeper and deeper circuits (ergo more valuable and classical intractable problems we wish to solve).
When you read about systems needing 1:1000 ratios of physical qubits to create logical, error corrected qubits, and huge power plants to make the system work = it’s pointing at architectures trying to overcome these fundamental challenges.
We’ve already solved those, and don’t have those problems. We’ve solved the problems historically associated with trapped ions (scaling advantage, complex laser control systems) — and are cooking with a full semiconductor approach and electronic qubit control. Will expose more on this in the future.
If you want to understand that “level 3” answer more deeply (and the observation about how these principles are amplified by FTQC) — I’m going to also hit on that in my next post.
Thanks for double-clicking on this with me. There’s a ton happening across the industry, and learning how to filter noise from signal is important.
메타데이터
- post_id
- 3f793c836ec0
- slug
- reality-rhetoric-customers-revenue-truth-3f793c836ec0
- url
- https://medium.com/@sakacc/reality-rhetoric-customers-revenue-truth-3f793c836ec0
- canonical_url
- https://medium.com/@sakacc/reality-rhetoric-customers-revenue-truth-3f793c836ec0
- author_url
- https://medium.com/@sakacc
- status
- ok
- fetched_at
- 2026-06-17 12:55:42