Why we built the simulators before the kits

Every roadmap we drafted in the first year started with a kit. It's the obvious starting point — robotics reads as hardware, and a classroom with nothing to touch doesn't feel like a robotics classroom. We built one anyway, and then didn't ship it first.

The reason was cost, not caution. A kit per student is the single biggest line item in any deployment, and it's the one that turns a willing school into a waiting school. Simulators let a class of forty run the same curriculum on whatever machines the computer lab already has, with the kit becoming an upgrade decision instead of an entry barrier.

The trade-off is fidelity, and we don't pretend otherwise. A simulated motor doesn't stall the way a real one does when the load is wrong, and there's a specific kind of debugging — the kind where the code is right and the wiring isn't — that only a physical build teaches. That's why the curriculum moves students from simulator to kit within the same module rather than treating them as separate tracks.

What changed in practice: schools that could never have justified forty kits could justify forty seats of software, and the ones who could afford kits from day one still start on the simulator, because the module is designed around the constraint, not around what a given school happens to be able to afford.

Hardware was always the plan. It just wasn't going to be the entry point, because a hardware seat per student is the thing that makes STEAM unaffordable at scale.