Saturday morning. My son is up at six. Cartoons are on. Cereal has been negotiated, rejected, renegotiated, and eventually consumed in a quantity that seems incompatible with the volume of mess it has produced. My wife is still asleep, which means I have approximately two hours before anyone needs me to do anything. Two hours. Maybe three if I'm lucky and the cartoons are particularly good.
This is my build window. This is when I ship.
I didn't plan to become a builder with a parenting constraint. Nobody does. But having a young son in London has, without question, made me better at building products. Not in spite of the limited time, but because of it. The constraint is the feature. When you have three hours on a Saturday morning and a real problem to solve, you don't waste time on things that don't matter. You cut everything unnecessary. You ship the thing that works, not the thing that is perfect. And you do it fast, because in about ninety minutes someone is going to need you to help find a shoe.
Build what you actually need
The best product advice I've ever received didn't come from a book or a conference or a mentor. It came from a Saturday morning in January when it was raining, my son was bored, and my wife asked the question that every parent in London dreads: "So what are we doing today?"
I did what I always do. I googled. I scrolled through various websites and apps trying to find something - anything - that was both age-appropriate, reasonably close, indoors, and not yet another trip to the same soft play centre we had been to fourteen times already. The information was out there, scattered across twenty different sites, none of which were designed for the specific question I was asking: what can we do today, right now, with my son, in this weather, near where we live?
So I built Little London. A directory of things to do with a young child in London. Not a comprehensive guide to everything. Not a review site. Not a booking platform. Just a clean, fast, curated list of real places and activities, organised by type, filterable by area, updated regularly. The product I needed but couldn't find.
That is the pattern. Every product I've built for my family started the same way: a real frustration, experienced in real time, with no satisfactory existing solution. Forest Quiz happened because my son wanted a game about Nottingham Forest and nothing existed. The First Out app happened because I was tired of not knowing where to stand on the tube platform for the school run. Forest Flash Cards happened because my son wanted to test each other on player stats.
None of these started with market research. None of them started with a competitor analysis. They started with a need. My need. My family's need. And that's why they work - because I'm not guessing what the user wants. I'm the user.
The harshest users you'll ever meet
Children are, without exception, the most demanding and unforgiving users of any product. They have zero patience. Zero tolerance for anything that doesn't work immediately. Zero interest in your explanation of why the loading state is taking a bit longer than expected. If it doesn't work in three seconds, they're gone. They've moved on to something else. They're already asking for a snack.
This is brutal. It's also incredibly useful. Building products for my son taught me more about user experience than any design course or UX book ever could. When my son played the Forest Quiz for the first time, he didn't read the instructions. He didn't explore the interface. He just tapped the thing that looked most tappable and expected something to happen. If something didn't happen immediately, he told me it was broken.
That feedback loop - immediate, honest, utterly devoid of politeness - is the most valuable thing a builder can have. There's no awkward user testing session where someone tries to be nice about your product. There's just a child who either uses it or doesn't. Who either enjoys it or walks away. Who either asks to play again or never mentions it.
My son doesn't care that I built the thing. They don't care about the code or the design or the clever way I handled the state management. They care whether it is fun. Whether it works. Whether they want to use it again tomorrow. That's product-market fit, distilled to its purest form.
Constraints breed creativity
I hear people talk about needing more time, more resources, more budget to build things. I understand the impulse. But I also know, from experience, that constraints aren't the enemy of good work. They're the engine of it.
When you have three hours, you can't build a complex multi-feature application with user authentication and payment processing and an admin dashboard. You can build one thing that does one thing well. And that, more often than not, is exactly what users actually want. A quiz that works. A directory you can browse. A guide that tells you where to stand. Simple, useful, done.
The Saturday morning constraint forced me to think in terms of minimum viable products before I even knew what that phrase meant. What's the smallest version of this that would be useful? What can I cut without losing the core value? What does the user actually need, right now, this minute? Not what they might want in six months. Not what the roadmap says. What they need right now.
Parenting teaches you this instinctively. When a child asks for something, they mean now. Not after the next sprint. Not in Q3. Now. And if you can't deliver now, you need to deliver the simplest possible version of what they want, right now, and iterate later. That is shipping. That's the discipline that three-hour build windows create.
The personal need advantage
There's a reason that some of the best products in the world were built by people solving their own problems. When you're the user, you have an advantage that no amount of user research can replicate: you know what the problem feels like. Not what it looks like in a survey response or a user interview. What it actually feels like, in the moment, when you're standing in the rain with your kid and no plan.
Every one of my family-facing products has that quality. They were born from a specific, felt frustration. And they were tested by the most demanding users imaginable: a kid who doesn't care about your feelings and a partner who just wants to know what they're doing this weekend.
The products I've built for my son aren't my most technically impressive work. They aren't the ones I would put first in a portfolio for a technical audience. But they're the ones that get used. Actually used, by actual people, for actual purposes. My son plays Forest Quiz regularly. They browse the flash cards. We use Little London almost every weekend. First Out gets checked before most tube journeys.
That is the measure. Not how clever the code is. Not how beautiful the design is. Not how impressive the technology stack is. Does it get used? Does it solve the problem? Does it make someone's Saturday morning a little bit easier?
Having a son made me a better builder because it gave me something that no course or mentor or framework could: a genuine need, a hard constraint, and an honest critic living in my house. The rest is just building.
