How We Built 240 Science Labs (And What We Learned)

When we started SciFunLab, we had a simple goal: build science simulations that actually teach something. Three years later, we have 240 labs covering physics, chemistry, biology, earth science, and engineering. Here is the honest story of how we got there — including the parts that did not go according to plan.

The First Version Was Wrong

Our first prototype was built with a physics engine designed for game developers. It looked great. Balls bounced, pendulums swung, fluids sloshed. We showed it to a group of high school teachers and felt proud.

The feedback was crushing. "This is fun," one teacher said carefully, "but I cannot use it to teach anything specific. The students will play with it for ten minutes and learn nothing." She was right. We had built a toy, not a learning tool.

The difference between a simulation that entertains and one that teaches comes down to constraints and curriculum alignment. Students need to be able to change specific variables, see specific outputs, and connect what they observe to concepts they are studying. Freeform playgrounds do not do that.

We threw out three months of work and started over.

The Technical Stack That Actually Worked

Version two was built on different foundations. We chose to separate the physics engine from the rendering layer, which let us optimize each independently. The physics runs in a Web Worker so it never blocks the main thread — no matter how complex the simulation, the interface stays responsive.

For rendering, we use WebGL for the simulations that need it (fluid dynamics, electromagnetic field visualizations, molecular interactions) and Canvas 2D for simpler ones. The choice matters: a pendulum simulation does not need a GPU, but a fluid simulation with thousands of particles absolutely does.

The most important architectural decision was building a "curriculum layer" on top of the physics layer. Every simulation has a configuration file that specifies which variables students can control, what range each variable spans, what outputs are visible, and what learning objectives the simulation is designed to address. Teachers can lock certain variables, set starting conditions, and define challenge scenarios — all without touching code.

The Hard Problem: Getting Physics Right

Making something look like physics is easy. Getting the numbers right is hard.

We discovered this building our circuit simulation. The basic Ohm's Law version was straightforward. But when we added capacitors and inductors, we needed to solve differential equations in real time. At high simulation speeds, numerical integration errors accumulated and the simulation diverged from reality. Students would get answers that were off by 40%.

We spent six weeks on this one problem. The solution involved implementing adaptive step-size integration and capping simulation speed when the timestep would produce unacceptable error. It is invisible to students, but it means the numbers they see match what they would measure in a real lab.

We have stories like this for almost every simulation. The chemistry stoichiometry lab required modeling reaction kinetics correctly enough that the relative rates of competing reactions are accurate. The wave optics simulation needed proper handling of coherence and interference. The orbital mechanics simulation required switching between integration methods depending on the scenario.

Each one took longer than expected. Each one taught us something.

What Made the Difference: Teacher Partnerships

The technical challenges were solvable. The harder problem was educational design.

We partnered with 34 teachers in our first year, giving them early access in exchange for structured feedback. They told us which simulations matched their curriculum, which variables students fixated on (usually not the most instructive ones), and which interfaces confused instead of clarified.

One insight changed how we build everything: students need a reason to interact. A simulation with no goal is a screensaver. We now build every lab with what we call a "discovery question" — a specific, answerable question that students work toward. The simulation is the tool; the question is the purpose.

Another teacher pointed out that our color choices for graphs were inaccessible to students with color vision deficiency — roughly 8% of male students. We rebuilt our entire color system around accessibility standards. It took two weeks and made every visualization better for everyone.

Where We Are Now

At 240 labs, we cover most of a standard K-12 science curriculum in the United States, UK, and Australia. We have started adapting content for IB, AP, and A-Level syllabi based on teacher requests.

The platform serves roughly 85,000 students per month. We see average session lengths of 22 minutes per simulation, which is far longer than we expected. The discovery questions work.

We are building lab 241 now: a simulation of protein folding that connects to CRISPR and gene editing concepts. It is the most technically complex thing we have attempted.

We expect it to take longer than planned. We expect to learn something unexpected. That pattern has not failed us yet.