One codebase, three products.

The platform had to reach three kinds of customers: individual users in the cloud, universities running their own install, and classrooms that need a small offline box. Each one wanted different features and licensing. Keeping three separate forks would have tripled every fix.

1. 01 · ClientNext.js + React, Monaco in-browser editor, Three.js circuit and Bloch-sphere views
2. 02 · AccessFastAPI services, IAM, licenses with feature bits, org-scoped API keys, Redis rate limiting
3. 03 · ExecutionCPU and GPU simulators (CUDA-Q, tensor networks), real QPU jobs on IBM Quantum, async outside the request path
4. 04 · DistributionsCloud · Academia · Raspberry Pi edge appliance, from one core codebase
5. 05 · Data & deliveryPostgreSQL, Redis, SQLite on the edge, GHCR images, self-hosted CI, staging → production

• One codebase, three distributions

  A shared core layer used by all four backend services, with each distribution switching features on through configuration. Consolidating it deleted about 3,000 lines of code that had drifted apart.

• Real hardware execution

  “Run on QPU” sends circuits to IBM Quantum as an async submit-then-poll flow. Hardware jobs are never retried automatically, so one click can never become two paid runs. Alongside it: a CUDA-Q error-correction composer, a noise composer, tensor-network simulation and live circuit and Bloch-sphere views.

• Licensing and billing

  A product catalog, per-product licenses with feature bits checked in every service, org plans, org-scoped API keys and Razorpay checkout with autopay. That covers the whole path from “Buy plan” to a licensed user.

• Infrastructure

  The edge appliance delivered and verified on real Raspberry Pi hardware, plus a GPU dev server, container images on GHCR with self-hosted CI, Redis rate limiting that holds across replicas, a 3-tier staging and release flow, and Helm charts for GPU node pools.

• Security

  Hardened authentication and CORS across four services, and added secret scanning to CI.

From “Buy plan” to a licensed user: the payment provider confirms first, then every service sees the same new feature bits.

A run on real hardware costs money and queue time, so the whole path is built so that one click is one run.

1. 1

   Configuration over forks

   One core with per-distribution config costs more design up front, but every fix ships everywhere at once.

2. 2

   No retries on hardware

   Simulator jobs retry freely. Hardware jobs fail safe and ask the user, because a duplicate run costs real money and queue time.

3. 3

   Licenses as feature bits

   Every service checks the same bits, so a plan change takes effect everywhere without special-case code.

4. 4

   Rate limits in Redis, not in memory

   The API runs as several replicas. A limit kept in one process's memory lets a user through once per replica, so the counters live in Redis and hold across all of them.

Moving the deployment to Kubernetes, starting from the Helm charts for GPU node pools that are already in place.