Quantum computing is usually taught one of two ways: as pure linear algebra, or as raw Qiskit code. Neither helps if what you actually want is to see what a Hadamard gate does to a qubit before you can write its matrix.
Qonstruct is the thing in between. A sequenced curriculum of lessons with interactive visualizations built into them, a drag-and-drop circuit editor covering the full 48-gate IBM Qiskit standard set, and a Sandbox for building whatever you like. Circuits run server-side on a real Qiskit Aer simulator and come back as state vectors, measurement probabilities and rendered Bloch spheres. On top of that: an AI tutor with context on the lesson you are in, and the usual gamified scaffolding of XP, levels and badges to keep a self-directed learner moving.
It is a React and TypeScript single-page app over a Python FastAPI service, with async SQLAlchemy on PostgreSQL, JWT auth, and Qiskit doing the physics.
Still being built
This one is live-ish and unfinished, and it is worth being specific about which parts are which. The curriculum, the circuit editor, the simulator, auth, progress and the AI tutor all work. The subscription tier is modelled end to end and the payment call itself is still simulated, so nothing charges anyone yet. The most recent work has been pulling the quantum curriculum out into a pluggable domain module so the platform underneath it is subject-agnostic, which means a good part of it is mid-refactor at any given time.
What makes it hard
The circuit format is a contract between three parties. The editor validates a circuit in the browser, the API validates it again on the way in, and Qiskit is the only one of the three that can prove any of it correct. Add a gate to one side and not the others and you get the worst possible outcome: a circuit that passes validation and then simulates wrong, quietly, with a plausible-looking state vector.
So the ground truth had to come from the maths rather than from agreement between my own components. There is a validator that checks every gate matrix against Qiskit's own reference operators: unitarity, determinant, eigenvalues, to a tolerance of 1e-10. It is the only thing standing between "the UI accepted it" and "it is right", and building it changed how I think about where a test should point. Asserting that two of my own layers agree is nearly worthless when both can be wrong in the same direction.
The other thing I would carry anywhere is the test setup. Each test worker gets an isolated database and every test runs inside a transaction that is rolled back, rather than creating and dropping schemas. That is the difference between a suite you run constantly and one you avoid.
What I took from it
- A test that compares two of your own layers proves they agree, not that they are correct. Point it at an external source of truth wherever one exists
- Async all the way down is a decision you make once and live with everywhere. It is worth it, and it is not free
- The interesting part of an education product is sequencing, not content. Deciding what has to be understood before what is most of the design
- Working to a written plan in phases beats improvising, on a project this size and on my own. It is also what made it possible to pick the work back up after putting it down
- Physics does not care how good the UI is
Where it goes next
Finishing the domain module extraction, then real payments, then the instructor side: organizations, classrooms and enrollments are already in the data model, which is the direction the whole thing is heading.