How a Learning App Is Actually Built (and Why That Should Matter to Parents)

I've been writing software for about fifteen years, and a few years ago my wife and I built a math app for our own two kids because I couldn't find one I trusted to have on our kitchen table. Building it taught me something I wish more parents knew: how learning apps are built tells you almost everything about whether they're trying to teach your kid or just keep him tapping. The features aren't neutral. Every one of them is a choice, and the choices point in a direction.

Let me walk through how one of these actually gets made, because the sausage-making is where the honesty is.

Every app starts with one question the team answers early

Before a single screen gets designed, somebody on the team answers a question, usually without saying it out loud: what does success look like?

For some teams, success means the kid learns the material and eventually doesn't need the app anymore. For a lot of teams, success means the kid opens the app tomorrow, and the day after, and keeps a streak going for two hundred days. Those two answers produce completely different products, even if both say "educational" on the store page.

You can feel the difference as a user. An app built to teach is trying to work itself out of a job. An app built for engagement is trying to become a habit. Both can be polished and colorful and full of encouraging sounds. Underneath, they're pulling in opposite directions, and the tug-of-war shows up in the small decisions.

The reward system is the tell

Here's the piece I'd inspect first, because it's the hardest thing to fake.

Every kids' app has some reward loop: points, coins, badges, a little character that gets happy. The question is what triggers the reward. Two apps can both hand out coins, and the coins can mean totally different things.

• Reward for time spent: the kid gets coins for staying in the app, so the app is incentivized to keep him there, doing anything.
• Reward for problems attempted: better, but a kid can still farm easy problems he already knows.
• Reward for real progress: the kid earns something when he gets harder material right, or masters a skill he was stuck on.

That third one is much harder to build. I know because I built it, and it took real work. You have to track what each kid actually knows, decide what "harder" means for that specific kid, and detect genuine mastery instead of lucky guessing. It's tempting to skip all that and just reward minutes, because minutes are trivial to measure and they look great in your usage numbers. When I see an app that rewards time or raw taps, I don't assume the makers are villains. I assume they took the cheap path, and the cheap path happens to train kids to grind.

Watch what happens when a kid gets something wrong

This is the moment that separates a teaching tool from a game with a math costume.

When my kid gets a problem wrong, what does the app do? A teaching tool does something with that mistake. It shows the step he missed, or gives a hint, or nudges the difficulty down so he can rebuild confidence, or brings that exact skill back a few minutes later to see if it stuck. A weaker app just flashes a red X, deducts nothing, and lets him guess again until he stumbles onto the right answer.

That "guess until it's right" pattern is a red flag, and it's an easy one to spot from the couch. If a kid can brute-force his way through by tapping every option, the app isn't measuring understanding. It's measuring persistence, and it's teaching him that math is a lock you pick by trying every key. Building the better version means writing logic that responds to the specific wrong answer, which is more work than accepting any correct tap. Teams that skip it usually skip it on purpose.

Adaptive difficulty is real, and it's expensive to do right

Parents hear "adaptive" a lot, and it's a genuinely valuable feature when it's real. The idea is simple: the app should give a kid problems that are a little bit hard, not too easy and not crushing. That's where learning actually happens.

Doing it honestly is harder than it sounds. You have to keep a running model of what the kid knows, notice when he's mastered something and stop drilling it, notice when he's floundering and back off, and do all of that without making it obvious or frustrating. When we built ours, the difficulty engine took longer than almost anything else, and it's still the part I tinker with most.

A lot of apps advertise "adaptive" when what they really have is a fixed staircase: everybody climbs the same levels in the same order, and "adaptive" just means the levels get numerically bigger. That's not adjusting to your kid. That's a treadmill with a speed dial. The way to test it is to watch a session. If a kid who's clearly bored keeps getting the same kind of problem, the adaptation isn't there.

What to actually do with this

You don't need to read code to judge an app. You need to watch one honest session and ask a few questions the way an engineer would ask them.

• What is this app rewarding: time, taps, or real progress?
• When my kid is wrong, does the app teach him or just let him retry?
• When my kid is bored, does the difficulty actually move?
• Could my kid look successful here without getting any better at math?

That last one is the whole game. If a kid can rack up a huge score, a long streak, and a pile of coins while learning nothing, the app was built to look educational, not to be educational. The people who made it knew the difference when they built it. Now you know it too, which means you get to be the one deciding what sits on your kid's screen, instead of trusting a store rating and a cheerful icon.