When curiosity is sparked...

I stayed up late last week trying to record a lecture video on action potentials for my Neuroscience class. I kept redrawing the neuron, restarting the recording, trying to get the sequencing right. After about an hour of frustration, I stopped and asked myself a different question: why am I making a video at all?

What I actually wanted was for students to explore the process of an action potential unfolding, to interact with it, to discover the pattern before I named it. A video is passive. It shows. It tells. What I needed was something that let students do.

So I built an app instead.

Build What You Need

Using Claude Code, I built a small interactive simulation that scaffolds the action potential process for students. It is tailored specifically to my class, my sequence, my learning goals. No extra features, no unnecessary information, no generic PhET simulation that shows too much too soon. Just the right amount of discovery at the right moment.

Here is the thing that surprised me: the app took less time to build than the video would have taken to record and edit. And it does something a video never could. It lets students interact, explore, and arrive at understanding on their own terms.

The shift: I was not looking for a tool. I was not shopping for a simulation. I was building exactly what my students needed, and the act of building it forced me to think more carefully about the learning experience than any lesson plan ever would.

I shared both apps with my colleagues this week. The Action Potential App and the Demyelination App are live. They are simple, purposeful, and built for inquiry. If you want to see what "build the tool" looks like in practice, start there.

Is Software Dead?

This experience pushed me into a bigger question that I have been turning over for weeks: is traditional educational software dead?

Think about it. We used to search for the right app, the right simulation, the right platform. We evaluated SaaS products, compared features, sat through demos. And most of the time, the tool was close but not quite right. Too broad, too narrow, too cluttered, too rigid.

Now students can build their own. A student struggling with organic chemistry can use Claude to generate a tailored study app. A student mapping historical events can create a custom timeline tool. A student learning Arduino can build a simulation specific to their project. The combination of Claude and NotebookLM has quietly made one-size-fits-all software feel like a relic.

The question I keep coming back to: should we be teaching students how to dynamically create tools in response to their own learning needs? Not coding for coding's sake, but building as a form of thinking. The app is not the product. The app is the process.

Rigor and Creativity in the Same Breath

There is a tension I feel every week between wanting rigorous, measurable learning and wanting students to create freely. Grading makes it harder. Standards make it harder. The instinct to control the outcome makes it harder.

But here is what I am learning: when students build something, the rigor is embedded in the building. You cannot build an action potential simulation without understanding action potentials. You cannot create a study tool without deeply engaging with the content. The creative act and the rigorous thinking are not in tension. They are the same thing.

The challenge is designing assessment structures that honor this. Standard grade formats were not built for student-created software. They were built for essays and exams. I do not have a clean answer yet, but I think the answer lives somewhere in the process documentation, in the iteration, in the visible thinking that building requires.

The real question: How do we build classrooms where rigor and creativity are not competing values but inseparable ones? Where the standard and the project are the same thing?

I am still working on this. But the action potential app taught me something I did not expect: sometimes the best lesson plan is not a plan at all. It is a tool that did not exist until you needed it.

Resources

• Action Potential Interactive App
• Demyelination Interactive App

A student in my neuroscience class blinked. A lot. That's not remarkable in itself — we all blink. What was remarkable was the question that followed: How many times do we blink in a minute? And does it change when we're focused?

In the past, I would have Googled "blink counter app," scrolled through the App Store, found something close, settled for something mediocre, and moved on. Instead, I built one. Right there. During class. An app that counts blinks, times them, and gives students real data to analyze.

This is the shift I can't stop thinking about.

The Problem-Solver's Instinct

We've spent years training ourselves — and our students — to be tool finders. Need a timer? Find one. Need a quiz platform? Compare five. Need a simulation? Hope someone built one. The entire edtech ecosystem is built on the assumption that teachers are consumers of tools built by someone else.

But what happens when you can build the tool yourself? When the distance between "I have a problem" and "I have a solution" collapses to minutes instead of months?

Building apps to solve problems rather than looking for tools to solve problems is very metal. Solving your own problems through invention just might be the next AI-powered critical thinking.

My own app, Spark Learning Inquiry Studio, is an example of this. I had a problem: inquiry-based lesson design is powerful but hard to structure, hard to present, hard to share. No tool existed that thought the way I think about the 5E learning cycle. So I built one. And it continues to evolve because it's mine — it solves my problems.

Students as Builders

Here's where it gets exciting: students can do this too. Not hypothetically. Right now.

Jacob, a student in my Design for Social Good class, needed a way to test assistive technology connections for the Xbox Adaptive Controller. There's no app for that. So he built one: an Arduino-based testing interface that solves a real problem for real users. He didn't find a tool. He became the toolmaker.

This is what I mean by "app slop" used for good — quick, purpose-built applications that solve specific problems. They don't need to be polished. They don't need to scale. They need to work.

The Classroom as Laboratory

This week I used a Slinky to get my neuroscience students thinking about perception and time delay. A simple warm-up in Spark Learning — watch the Slinky drop, notice the delay between what you see and what you feel, and wrestle with why. In chemistry, we used Jenga blocks to model the molecular instability of nitrogen triiodide. The tower wobbles. You hold your breath. Then it collapses — just like the compound.

These aren't tech moments. They're inquiry moments. The Slinky and the Jenga tower are tools I built into a learning cycle using the same app I built to solve my own problem. The technology isn't the point. The thinking is the point. The technology just makes the thinking visible, shareable, and structured.

The Question

Here's what I keep coming back to: What's a problem you have? Not a tool you need — a problem. And what would happen if you — or your students — just... built the solution?

I think we're entering an era where the ability to identify a problem and invent a solution is more valuable than the ability to find and evaluate existing tools. That's a different kind of critical thinking. And AI makes it accessible to everyone — not just developers.

Something to sit with this weekend.

— Ramsey

Resources

• Spark Learning Inquiry Studio — Inquiry-based instructional design
• Jacob's Arduino Assistive Tech App — Student-built problem solving

Cycles of Learning — Ramsey Musallam
cyclesoflearning.com