Two pathways

Domain/Industry Expert and Builder/Developer Expert

Or: why you should come to a quantum hackathon even though you are not a quantum physicist

This guide is for both pathways. The Domain/Industry Expert brings a field they know, and coding is optional in that role. The Builder/Developer Expert pathway is the coding role. Both share the problem, the comparison, and the write-up.

Florida Qiskit Fallfest Hackathon, part of Qiskit Fall Fest 2026.

Read this first

Bring your curiosity. We’ll help with the qubits.

You belong in this room if quantum computing is new to you. The Domain/Industry Expert pathway is a full role. You know which problems are real, which constraints bind, and what a useful result would mean in your field. A builder can learn a circuit in a weekend. Your context took longer than that, and the team needs it.

Here are two simple ways to prepare: create your IBM Quantum account and start thinking about a problem or topic that interests you. No prior quantum experience is required—we’ll guide you through the rest together.

The algorithms are in textbooks. The code is on GitHub. IBM Quantum gives you a real quantum computer from a browser tab, on the free Open Plan. What makes a project memorable is someone who can say, with care, "that's not how procurement actually works," or "our routing constraints look like this," or "even if this worked perfectly, the regulator would ask a different question, and here's why."

Two pathways

Every team should include both perspectives. A builder-only team may create a clean implementation before confirming that the problem matters. A domain-only team may frame a strong opportunity without a testable experiment. The strongest projects come from combining the two.

Builder/Developer Expert

You may use Python and Qiskit. You may build, transpile, and run circuits on simulators and approved hardware. You may implement the quantum experiment, create or measure the classical baseline, and collect configurations, metrics, plots, and results. You may maintain reproducible notebooks and code, and document technical limitations. Python is expected. A physics degree is not required. At this level much of the work is linear algebra, structured problem mapping, and using APIs correctly.

Domain/Industry Expert

You may bring expertise from finance, logistics, energy, health, law, policy, agriculture, manufacturing, venture capital, operations, or another field. You may confirm that the problem exists, name the stakeholders and the business or community value, and describe how it is solved today. You may set the classical baseline and the meaningful metrics, and weigh feasibility, risk, policy, ethics, and deployment. You may judge whether the output matters, and lead USE-CASE.md, LIMITATIONS.md, the presentation, or the narrative. Coding is optional. You do not need to install Python. You may read notebooks without writing them. This pathway is a full role.

Shared responsibility

The same guide is rendered on this page: Two pathways. The participant handbook keeps the project types and this matrix in §3. A public note is Domain track, Entangled Solutions Group (opens in a new tab).

If you are wondering whether you are “technical enough,” read the complete Domain/Industry guide before deciding not to participate. Your industry knowledge may be the part the team cannot replace with code.

Day-one jobs inside a team, industry prompts, and the use-case canvas follow. Project types, including a mapped problem, a benchmark, a tool, and an analysis, are in the handbook: What you are actually going to build.

1. The actual argument

1.1 Quantum computing's bottleneck is not physicists

There is a shortage of people who can implement a variational quantum eigensolver given the number of jobs available today and universities are now starting to produce them continuously. What the field is visibly short of is people who can connect the machinery to a problem that a real organization would pay to solve.

You can watch this play out in the literature. A large fraction of published quantum "applications" work is physicists picking a problem that is mathematically convenient, solving it, and describing it in language that anyone who works in that industry would find slightly off. Portfolio optimization papers that ignore transaction costs and regulatory capital. Logistics papers that optimize a route without modelling the driver-hours rules that actually bind. Drug discovery papers that compute a molecular property that isn't the one medicinal chemists care about.

That gap runs in a useful direction: it is often easier for a domain expert to learn what a quantum computer can do than for a quantum specialist to learn what your industry needs.

That is why this pathway exists, and why it is equal to the coding pathway.

1.2 What "understanding quantum well enough" actually requires

You need to hold roughly three ideas. Not the mathematics of them, but the shape of each one.

One. A quantum computer is not a faster computer. It is a differently-shaped computer. There is a small, specific set of problem structures where it may eventually do something classical machines find hard, and a very large set where it will never beat your laptop. Knowing which is which is 80% of being useful here, and it's a taxonomy question, not a physics question.

Two. Today's machines are noisy and small. Real quantum computers make errors constantly. We manage this with error mitigation, statistical correction after the fact. Full error correction, the thing that makes arbitrarily long computations reliable, is a future technology that's closer than most originally thought. This means: today's demonstrations are small, and the honest framing of almost any hackathon project is "here is the pattern, at toy scale, and here is what would have to change for it to matter in the not too distant future."

Three. Nearly everything practical is hybrid. A classical computer does most of the work and hands one specific sub-problem to the quantum processor. The interesting engineering question is almost always where's the seam. In other words, which piece of a workflow is worth handing over. That is a systems and process question, and it is a place where your experience matters.

Those three ideas are enough to start. We will practice them together. IBM's Quantum business foundations (opens in a new tab) course covers all three in about three hours, and it ends with a Credly badge. It is an optional next step written for this pathway.

1.3 The three problem shapes

The taxonomy below is the part to keep nearby. On day one, we will match something from your world to one of these three shapes. There is no prize for rushing, and "not presently one of these shapes" is a valid, useful answer.

Shape 1, Optimization: "find the best arrangement out of an astronomical number"

You have many discrete choices, they interact with each other, and the number of possible combinations explodes. You're currently using heuristics that give a decent answer, not the best one, and you've quietly accepted that.

Sounds like: scheduling, routing, portfolio construction, network design, crew rostering, warehouse slotting, load balancing, bin packing, facility location, supply chain configuration.

The tell: somebody in your organization runs a solver overnight and it doesn't always finish.

A friendly check: classical optimization is already very strong, with decades of engineering behind it. A project here is at its best when it names the classical baseline and stays honest if that baseline is still ahead. That honesty is a strength of this pathway.

Shape 2, Simulation: "model a quantum system with a quantum system"

Molecules and materials are quantum systems. Simulating them classically means approximating something that is natively quantum, and the approximations get expensive fast. This is the application where the theoretical case is strongest, because the match between problem and machine isn't a metaphor.

Sounds like: drug candidate screening, catalyst design, battery chemistry, novel materials, photovoltaics, nitrogen fixation, protein-ligand binding, semiconductor design.

The tell: your R&D people say "we'd have to synthesize it and find out" or "DFT isn't accurate enough for that system."

Watch out for: the molecules within reach of current hardware are small enough to be chemically uninteresting. Framing matters enormously here.

Shape 3, Learning and data: "find structure classical methods can't see"

Quantum circuits can compute similarity measures between data points in ways that are hard to reproduce classically. Whether that ever translates to better predictions on real data is genuinely open.

Sounds like: fraud detection, anomaly detection, classification on small high-dimensional datasets, generative modelling, risk scoring.

The tell: your data is scarce and expensive rather than abundant, and the signal is subtle.

Watch out for: the most contested of the three. Excellent territory for an honest, skeptical project; poor territory for a bold claim.

If your problem doesn't fit any of these, say so. "We investigated whether X in our industry is a quantum-shaped problem and concluded it isn't, and here's the analysis" is a strong hackathon submission. A careful "not this shape" is as welcome as a small circuit.

2. Who specifically should come

Business and operations leaders. You know where the money and the bottlenecks are. You also know which "efficiency gains" are real and which are the kind that evaporate on contact with the org chart. Quantum will eventually arrive as a procurement decision on someone's desk. Understanding it before then is not a hobby.

Policymakers and public sector. Export controls, standards, research funding, post-quantum cryptography migration timelines, national strategy. All of these decisions are being made now, largely by people briefed by vendors. A weekend at a hackathon gives you a calibrated sense of the gap between demo and deployment that no briefing will.

Investors and analysts. You are being pitched quantum companies. Some of those pitches are excellent and some are technically incoherent, and the difference is not visible from a deck. Spend two days watching people try to make this technology do useful things and your due diligence questions change permanently.

Startup founders. Whether or not you ever touch a qubit, the pattern-matching transfers: you'll leave with a sharper sense of which technical claims to discount. And if you are building here, a weekend with actual hardware is worth a month of reading.

Domain specialists of every kind. Chemists, logisticians, clinicians, traders, agronomists, actuaries, grid engineers, epidemiologists, lawyers, materials scientists. Any project touching your field is better with you in the room and worse without you.

Designers, writers, and communicators. Every team explains the work in about five minutes. That explanation is a real part of the project, and this pathway is where it lives. You are welcome here.

Students in any discipline. Including, especially, the ones outside STEM. Some of the sharpest use-case work at these events comes from people whose first question is "wait, why would anyone want that?"

Absolute beginners with curiosity and no credentials. This is a real category and you are welcome. A question that feels basic is often the one that improves the project. Bring your curiosity. We’ll help with the qubits.

3. What you'll actually do

Pick a role on day one, or try one on and change it. These are real jobs on the team. We will help you get started.

🎯 Domain Lead

You are the source of truth about the problem. When the builders make a modelling assumption, you say whether it's acceptable. When they simplify, you say what breaks. You write USE-CASE.md.

Deliverable: a problem statement precise enough that a stranger in your industry would nod at it.

🔍 Problem Framer

You do the translation. You sit between "we want to reduce empty-mile freight" and "this is a constrained optimization over binary assignment variables." Writing the QUBO is optional. Getting the problem into a shape a builder can start from is the work, and we will help with the quantum words.

Deliverable: a written decomposition of the problem, variables, constraints, objective, and which constraints are hard versus negotiable.

📊 Impact and Feasibility Analyst

You do the arithmetic that makes the project credible. What's the classical baseline? What's a 1% improvement worth in currency? What's the smallest instance that would still be commercially meaningful, and how far is it from what ran on hardware today? This is spreadsheet work and it is enormously valuable.

Deliverable: a one-page quantitative case, with the resource gap stated plainly.

🎤 Storyteller / Pitch Lead

You own the five minutes that decide everything. You build the narrative, the visuals, and the demo flow. You also protect the team from itself: you're the one who says "we can't claim that."

Deliverable: the deck and the demo. A rough version is a fine start. We will help you rehearse it during the event.

⚖️ Policy and Risk Analyst

Regulatory constraints, data governance, procurement realities, security implications, ethical exposure. These matter especially in finance, health, energy, and the public sector. Naming them early makes the project more useful to the people who would have to live with it.

Deliverable: LIMITATIONS.md, plus the regulatory section of the use case.

💰 Investor-Lens Reviewer

You ask the questions a careful partner would ask. What's the moat? Who buys this, and from whose budget? What has to be true about hardware progress for the timeline to hold? Those questions make the work stronger, and the team can answer them together.

Deliverable: a written challenge memo the team has to answer.

4. Industry prompts

Not a menu to pick from, a demonstration of what "quantum-shaped" looks like in different fields, to help you find the equivalent in yours. Your version, with your specifics, will be far better than any of these.

Financial services: portfolio rebalancing under transaction costs and regulatory capital constraints | derivative pricing with path-dependent payoffs | collateral optimization across netting sets | fraud detection on sparse labelled data | credit risk with correlated defaults

Logistics and supply chain: multi-depot vehicle routing with driver-hours regulations | container loading and stowage | warehouse slotting under seasonal demand | resilient network design under disruption scenarios | last-mile consolidation

Energy and utilities: unit commitment across a mixed generation fleet | grid stability classification | optimal placement of storage on a distribution network | battery electrolyte chemistry | demand response scheduling across heterogeneous loads

Pharma and healthcare: protein-ligand binding affinity | reaction pathway analysis for synthesis planning | clinical trial site selection and patient allocation | operating theatre and staff scheduling | molecular property prediction with scarce data

Manufacturing and materials: catalyst discovery | production line sequencing with changeover costs | alloy and composite property prediction | predictive maintenance scheduling under spare-parts constraints | high-temperature superconductor screening

Telecommunications: spectrum allocation | network topology under redundancy requirements | antenna placement and beamforming | traffic routing under QoS constraints | post-quantum cryptography migration planning

Agriculture and food: crop rotation planning under soil, water, and market constraints | cold chain routing | fertilizer chemistry (the Haber-Bosch process is roughly 1–2% of global energy use: nitrogen fixation catalysis is a genuinely serious target) | yield prediction from sparse sensor data

Public sector and policy: emergency service positioning | public transport network design | vaccine and resource distribution under equity constraints | infrastructure investment sequencing | post-quantum cryptography readiness across government systems

Insurance: catastrophe risk modelling with correlated events | reinsurance portfolio structuring | claims triage | pricing in thin-data segments

Aerospace and defence: trajectory optimization | satellite constellation scheduling and tasking | structural and materials design | sensor fusion under uncertainty

5. The Use-Case Canvas

Fill this in before you arrive. One page. Bring it to team formation and read it out, this is how teams find each other.

Copy this block into submissions/team-<name>/USE-CASE.md when you form a team. That folder lives in the private project repository: https://github.com/robertloredo/FAU-Qiskit-Fallfest-2026 (opens in a new tab). Ask to join it.

# Use-Case Canvas

## 1. The problem
One paragraph. Assume the reader is new to your industry.
Plain language helps. If a teammate from another field would get lost, try one more pass. We can edit it together.

## 2. Who has this problem
Be specific. Not "banks": "mid-size asset managers rebalancing
multi-asset portfolios monthly under UCITS constraints."

## 3. How it's solved today
What tool, what algorithm, how long does it take, how good is the answer?
This is your baseline. It gives the later comparison something to stand next to.
If you don't know yet, that is a good first research question. We can work on it at the event.

## 4. What "better" is worth
Put a number on it. Currency, hours, lives, tonnes of CO2, error rate,
any unit. An estimate is welcome. "It would help" can become a number once you and the team look it up.

## 5. The quantum shape
Which of the three shapes is it? (Optimization / Simulation / Learning)
Why? What's the combinatorial explosion, the quantum system, or the
hidden structure?

## 6. The honest problem-size gap
How big is a real instance? How big can we run this weekend?
State both numbers. The gap is usually several orders of magnitude
and saying so out loud is a strength, not a weakness.

## 7. What would have to be true
For this to be deployable in five years, what has to happen:
in hardware, in algorithms, in your industry, in regulation?

## 8. What we'll actually build this weekend
A tiny, concrete, achievable thing. Not the vision. The demo.
"We map a 12-node instance of our routing problem to a QUBO,
run it on an IBM QPU, and compare to a classical solver."

## 9. Why anyone should care
Three sentences. This becomes your opening slide.

6. Your pre-work

No installation. The browser is enough. The labels match the handbook.

Required before participating. Follow §4 of the Participant Handbook and create your own free IBM Quantum account. That is the piece that lets you sign in. There is no shared login.

Recommended before the workshop. Open the IBM Quantum Composer (opens in a new tab) and drag gates around for about twenty minutes. Watch the visualizations respond. You will not need the mathematics yet, and that is completely fine. You are building a picture that makes later conversations easier. A draft of the canvas, even with empty boxes, gives team formation something to start from.

Optional next step. Quantum business foundations (opens in a new tab), about three hours, written for this pathway. There is an exam and a Credly badge at the end if you want a credential to share. Designing and leading quantum projects (opens in a new tab) is a further optional course about governing this kind of work. Two notebooks from the "Domain and industry" section of NOTEBOOK-CATALOG.md are a good read when you have time. That catalog explains how to read a notebook when the code is new, and it takes about ten minutes to pick up.

We will complete this together. Reading a notebook in the room, team formation, and the story of the project. A half-finished canvas is a wonderful thing to bring. Empty boxes are welcome.

7. The honest caveats

These notes help you describe the field accurately, including when a claim is larger than the evidence. They are here so the story you tell is one you can stand behind.

Quantum computers are not faster at most things. They are not a faster database, spreadsheet, web app, or neural-network trainer. A claim that quantum will make everything faster does not match how these machines work. You can say that kindly, and we will practice the wording together.

There is no commercially deployed result today in which a quantum method has replaced the best classical method in finance, pharma, or anywhere else. There are promising demonstrations and there is serious research. A project that claims otherwise, without the comparison written down, sits outside what this event asks. The glossary and the benchmarking page define that comparison. Naming the limit is part of a strong Domain/Industry Expert contribution.

"Quantum will break encryption" is real but widely misstated. It requires a fault-tolerant machine that does not yet exist. The genuine, urgent, present-day issue is harvest-now-decrypt-later: adversaries storing encrypted traffic today to decrypt in the future, which makes post-quantum cryptography migration a live planning problem right now. That's a legitimately good policy project. "Quantum computers will break Bitcoin next year" is not.

Timelines from vendors are often optimistic. That is true across the field. Noticing the gap between a slide and a working demo is a skill you can practice this weekend, and we will practice it with you.

Small demonstrations are legitimate; overclaimed ones aren't. Running a 10-qubit version of a problem that would need 10,000 qubits to matter is fine and normal and is what everyone does. Saying so is what separates good work from marketing.

Holding all of that and still finding the field interesting is the correct position. The technology is real, the trajectory is real, the timeline is uncertain, and the people who'll benefit most are the ones who understood the shape of it early, which is, again, why you should come.

8. Frequently asked, honestly answered

"Will I slow my team down?" Asking is how you help. A question that feels basic is often the one the room needed.

"What if I don't understand the presentations?" Nobody understands all of them. Not the physicists either, the field is wide and everyone is deep in a narrow strip of it. Ask.

"Do I need a team beforehand?" No. There's a team formation session at kickoff, and reading out your Use-Case Canvas is genuinely the best way to attract collaborators. Builders are actively looking for someone with a real problem.

"Is this only networking?" You will spend two days building a small project with people who care about the same questions. Conversations are part of that, and the work is too.

"I'm not a student. Can I come?" Whether a campus day is limited to enrolled students is TBA. Ask your local university lead, then Kevin Robinson at kevin@quantumglobalgroup.io. Capacity is up to 50 participants per campus.

"What if my industry has no quantum use case?" Then finding that out with care, and writing it up, is a complete project. A clear "not a fit yet" helps the field as much as a small demo does.

"I still feel underqualified." IBM's introductory course says you do not need a physics degree or years of programming. If you can follow a notebook and click Run, you can start. We will be there with you. Bring your curiosity. We’ll help with the qubits.

When you are ready, PARTICIPANT_HANDBOOK.md §4 is the account walk-through. Come say hello in https://discord.gg/vz6uTbtJzR (opens in a new tab) or by email to your local university lead, then Kevin Robinson at kevin@quantumglobalgroup.io.

Your industry knowledge is the part we cannot supply from a textbook. We will help with the qubits.