From a school project to a rover.

It started as a school project: a four-legged robot dog you controlled from your phone over Bluetooth. We called it CodeHound, and we were genuinely proud of it.

CodeHound was our spark. It was the first time we took an idea, built a real robot around it, and got it responding to code sent from an app over Bluetooth. Watching something we made actually move was the moment we got hooked on all of this.

We entered it into the 2024 Congressional App Challenge, poured a ton of work in, and learned a huge amount along the way. It didn't place - but that was never really the point. CodeHound had shown us exactly the kind of thing we wanted to build.

It was only later, as we thought about turning it into something real, that the limits showed. A walking robot dog is hard: to make it move well it would have to get bigger, more complex, and more expensive, and the app was still closer to a fancy remote control than a real way to learn to code. None of that took anything away from CodeHound - it just pointed us toward what came next.

That summer, we made a call we didn't take lightly: rebuild everything from the ground up.

We'd been thinking a lot about why learning to code feels so intimidating to most people. The numbers were hard to ignore. Only 43% of high schools in Arizona even offer a computer science course. And of the schools that do, only 2.3% of students are actually enrolled. The problem wasn't just access - it was that the tools available made programming feel abstract and unreachable. You stare at a screen, type text, and hope something works. There's nothing to hold. Nothing moves.

The rover came from asking a different question: what if the code wasn't abstract? What if you wrote a program and watched it physically execute in front of you, on something you built?

We redesigned everything. CodeHound's four legs became a small four-wheeled rover. The app was rebuilt from scratch - not a remote control, but a real coding environment with loops that repeat actions, conditionals with if/true/false logic, and variables that store and change values. We split it into two modes: a sandbox where you could experiment freely without limits, and a campaign where you progressed through levels as you learned each concept. The rover itself became modular - you could attach add-ons like a claw that the app could open and close, and the system would automatically recognize whatever module was plugged in. Unlock new parts in the app, attach them to the rover, and suddenly you had new blocks to code with.

We called it Roverdrive.

The timing of the redesign wasn't random. We were entering Roverdrive into Future Business Leaders of America's Mobile Application Development competition, and we built the new version specifically for it.

The competition prompt was to design a mobile app - specifically a game - that teaches a subject. We built Roverdrive around programming as the subject. The rover was the key: it made every concept tangible. A loop isn't just an abstract idea when you can watch your rover repeat the same path until you understand exactly why it's doing that.

It wasn't just about submitting an app. We had to stand in front of judges and present it - explain what Roverdrive was, what problem it solved, how it worked, and why we built it the way we did. We walked them through the app, showed them the rover, and made our case.

We placed 2nd in our region and finished in the top 10 in the state of Arizona.

It was the first time anyone outside our immediate circle had evaluated Roverdrive seriously. Watching judges engage with it - not just nod politely, but actually dig into how it worked and why - and come back with a high score was a different kind of confirmation than anything we could give ourselves. It meant the concept held up.

That same season, we also went back to the Congressional App Challenge, the same competition CodeHound had entered the year before. This time we submitted Roverdrive, and we were named a finalist - a sign of just how far the idea had come.

A few months later, we submitted Roverdrive to Open Sauce - an engineering convention in San Francisco where builders, makers, and inventors set up exhibits for the public. We applied not totally sure what to expect.

We got accepted.

We packed up the rover and flew out to San Francisco. At our booth, anyone who walked by could pick up a phone, open the app, and try to get the rover to do something. Kids, adults, engineers, people who'd never written a line of code. Some of them picked it up in minutes. Some needed a little help. But when someone finally figured out how a loop worked - because the rover was physically driving the same path over and over until they understood what was happening - and their face changed... that was the moment we knew Roverdrive worked the way we hoped it would.

The show confirmed something we'd suspected since the pivot. The physical robot isn't a gimmick. It's the whole point. Code stops being abstract when something moves because of it.

After Open Sauce, we started planning what Roverdrive should actually become. What we had was good. What we wanted to build was a lot better.

The app is being completely rewritten in Flutter with full 3D scenes - not the flat 2D interface of the current version. The drag-and-drop coding environment is staying, but everything around it is getting an overhaul. We're also building a real curriculum into it: structured learning paths that take someone from their first block all the way to writing loops and conditional logic, with every step reinforced by the rover physically executing what you code.

The hardware is getting its most significant upgrade yet. We're replacing the Arduino Nano with a custom-designed PCB - a circuit board built specifically for Roverdrive rather than a general-purpose development board. The rover will have a proper battery system with a dedicated charging port so you just plug it in, no swapping batteries. We're also adding an IMU - an inertial measurement unit - so the rover always knows exactly which direction it's facing. That opens up a whole new class of challenges where precision actually matters.

The modular system is being redesigned too. The current attachment mechanism works, but it's fiddly. The new version will have modules that connect cleanly, function more reliably, and are more practical to use. The goal is a system where a kid can swap a module in thirty seconds without needing help.

We've been accepted to exhibit at Open Sauce again in 2026. We can't wait to show people what this next version looks like.