Lead Product Manager at Coolblue · Tilburg
Building an app goes fast these days. The hard part is deciding what to leave out.
I make iOS apps on my own. Everything from the first idea to the App Store listing and the support mail afterwards. Below is what I shipped, what I left out of each one, and where this way of working runs into trouble.
A reflex game you play with one thumb. Decode the grid before it disappears, chain your hits, chase a high score.
5.0 ★ · 7 ratings
Turns two iPhones into a video baby monitor. Picture and sound go straight from one phone to the other, encrypted, and nothing gets stored.
5.0 ★ · 1 rating
Keeps track of a watch collection, logs what you wear, and exports a PDF for your insurer. No account: it syncs through your own iCloud and nowhere else.
A pond in a browser tab. Skip stones across it, ring the lilypads, watch the koi. Written from scratch in WebGL.
BabyBeam: what it costs to build a baby monitor without an account.
A baby monitor is either a separate device you use for two years and then put in a drawer, or an app that wants you to create an account so your child's bedroom runs through someone else's servers. That second option is most of the market. I get why it's built that way, but an app that puts a camera in a nursery and then explains why it needs an account has fixed one problem and created another.
Video and audio go straight between the two phones over WebRTC, end-to-end encrypted with DTLS-SRTP. Nothing gets recorded and nothing gets kept, because there's no server to keep it on. The only thing that ever leaves the two phones is a small pairing handshake. That one goes briefly through iCloud, encrypted with a key derived from the pairing code, which I don't have and can't recover.
This still works when you're not home. The two phones find each other over the internet, not just on your own Wi-Fi. What's gone is the account, the subscription, and the company in the middle.
Live and free to download. It's only been in the store a few weeks, so the honest answer to whether it worked is that I don't know yet. The ratings line above comes straight from the App Store and will say something once there's something to say.
AI writes most of the code in these apps. That's not the interesting part. It stopped being special somewhere around 2024, and a list of the tools I use tells you nothing about whether I can steer them.
The code is usually fine. It goes wrong in the text around it.
Three examples from this site. All mine, and all live for weeks before I spotted them. The crossed-out line is what the page claimed, underneath is what was actually true:
href="#". The button did nothing at all, and it went live like that.
None of these are bugs. They're claims that sounded right but weren't, in the one spot where only the person who built it can check. And I didn't catch them before they went live. I found them weeks later during a review. That changed how I work: text that comes out of AI now gets the same check as code that comes out of AI. Nothing goes live until I've held it against what the app actually does, including the legal pages nobody reads.
The other half of the work happens before that. Instead of prompting my way through every app from scratch, I set up a project structure and a set of written standards that I reuse. They spell out what “good” means for this kind of work, concrete enough that someone can actually follow it. So the tenth app starts where the ninth stopped.
That's the same skill you need in a team. Writing down what “good” means clearly enough that someone can work with it without you in the room is most of the job, whether that someone is a developer or a model.
Every app here started with the same question. Is this problem worth solving, who exactly has it, and what does a first version need to do before anyone cares? I look for something people already complain about, check whether the apps that exist actually fix it, and then write down the smallest version that's worth downloading. And I stick to that while I build.
Scope is only part of it. I also set the price, write the store listing, sort out the translations and the compliance paperwork, and decide what you get for free. Those are product owner decisions, and making all of them yourself is the fastest way I know to find out what each one costs.
In the end what matters is how the app feels to use. Something that does less but needs no explaining beats something that does everything and needs a manual.
Ten years in e-commerce, four of them leading a team. Right now I'm Lead Product Manager for Gaming, Printers & Office at Coolblue. I'm responsible for the strategy and the commercial results of those categories, and I coach six product managers and four product editors.
I've never had the product owner title. What I do have is ten years of being accountable for whether something worked commercially, and four apps where every product decision was mine.
I'm not looking for anything at the moment. But if you want to talk about product work, building things on your own, or how any of this came about, I'm always up for that.