Scope is the whole game
Projects rarely fail because nobody could write the code. They fail because the thing being built got wider than the time available, one reasonable-sounding addition at a time. Every one of those additions had a good argument behind it. That's what makes it hard to see happening.
On a team you at least have friction — somebody has to be convinced, an estimate gets revised out loud, a planning meeting forces the cost into view. Alone, there's no friction at all. I can decide at eleven at night to add a whole subsystem, and the only person who might push back is the one who just had the idea.
So the discipline has to be structural rather than a matter of willpower. I write down what version one is not before I write down what it is, and I treat that list as harder to change than the feature list. It's the only part of the process I've found that reliably survives contact with my own enthusiasm.
One user, watched closely
I have three children spanning Pre-K to third grade, and they are the most honest test group I've ever had access to. A six-year-old does not file a bug report. She doesn't politely work around a confusing screen or assume she's holding it wrong. She stops, puts the iPad down, and goes to do something else — and that silence tells you more than a page of feedback.
This is the part that's genuinely different from working at scale. At a large company you learn about users through instrumentation: funnels, cohorts, experiment results. Those are real and useful and I've built a career partly on them. But they're a compressed signal. Watching one child's face while she hunts for the shift key is not compressed at all.
The tradeoff is worth naming: three children in one household are not a representative sample of anything. Building for people you can watch buys depth at the cost of breadth. I'd rather start with depth and widen later than start with a survey.
Native isn't nostalgia
Everything here is SwiftUI, uses platform conventions, and works offline. That's not a preference for how things used to be — it's a set of specific properties I want.
It works when the network doesn't. On a plane, in a basement, in a car on the way to a grandparent's house. Software for children should never be a blank screen because a server is having a bad day.
Accessibility comes mostly for free. Dynamic Type, VoiceOver, Reduce Motion and the rest work because the platform already solved them. Reimplementing that stack badly is a choice I don't have to make.
It will still run in ten years. A native app with no backend has very few ways to rot. Nothing expires, no service gets sunset, no dependency gets abandoned. My daughter should be able to open this at sixteen and have it work.
White hat motivation
There's a gamification framework called Octalysis, developed by Yu-kai Chou, which maps human motivation onto eight core drives arranged around an octagon: epic meaning, accomplishment, creative empowerment, ownership, social influence, scarcity, unpredictability, and loss avoidance.
The useful part isn't the taxonomy — it's the split. Chou divides the drives into two halves.
White Hat drives sit at the top: epic meaning and calling, development and accomplishment, empowerment of creativity and feedback. These make people feel capable, in control, and good about the time they spent. They're powerful, but they carry no urgency — nothing about mastery makes you open an app right now.
Black Hat drives sit at the bottom: scarcity and impatience, unpredictability and curiosity, loss and avoidance. These are dramatically more effective at producing immediate action, and they leave people feeling anxious. This is the machinery behind streaks, limited-time events, loot boxes, and the notification telling you you're about to lose something you built.
Everything I build is designed White Hat first, and that is a real constraint with a real cost. White Hat motivation doesn't generate urgency, which means my apps will be less sticky than they could be, with worse retention numbers and fewer daily opens. I'm fine with that trade. I'm building software for children, and sticky is not a property I want in something my six-year-old uses.
In practice it looks like this. Key Quest runs on accomplishment and feedback: adaptive pacing so a child can feel themselves getting better at the specific keys they were bad at, and progression gated on genuine mastery. What it doesn't have is a streak counter that punishes a missed day, or a notification designed to interrupt dinner.
Dex Companion is the stranger case, because the game it accompanies already runs an extremely effective Black Hat engine — rare things, random encounters, the pull of the next one. That's the appeal and it works. Adding a second layer of it in a reference tool would be taking something that belongs to the game.
The things I won't build
Constraints are easier to keep than intentions, so it's worth writing them down where other people can see them.
- No accounts for children. If a feature requires a child to have a login, the feature is wrong. Progress lives on the device.
- No advertising. Not banners, not rewarded video, not "watch this to unlock." Children can't meaningfully consent to being sold to.
- No engagement mechanics. No streaks that punish a missed day, no notifications engineered to pull a kid back. A typing app should teach typing and then let go.
- No analytics on kids. No third-party SDKs, no behavioural telemetry, nothing leaving the device. This costs me real information about whether the app works. I'll take the hit.
- Nothing that needs a server to function. If the studio disappeared tomorrow, the apps should keep working.
Cadence, honestly
This is a nights-and-weekends studio. I have a full-time job running an engineering team and three children who reasonably expect me to be present, and I'm not going to pretend otherwise on my own website.
What that means in practice: fewer things, finished. I'd rather post nothing for six months than ship something half-done and spend the following six months apologising for it. There's no roadmap on this site, because a roadmap from a one-person studio is a wish list with dates attached.
When something is ready, it will appear. Until then the honest thing to display is the work in progress and the reasoning behind it, which is what this page is.