Jimmy Rentmeester

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.

Work

  1. GRID_BREAKER

    Arcade game · iPhone & iPad · Live

    A reflex game you play with one thumb. Decode the grid before it disappears, chain your hits, chase a high score.

    Cut
    The tutorial. There are sixteen campaign levels and each one adds a single mechanic, so you learn it by playing. Nothing to read before you start.

    5.0 ★ · 7 ratings

    GRID_BREAKER campaign screen: sixteen data cores across four chapters
  2. BabyBeam

    Baby monitor · iPhone & iPad · Live

    Turns two iPhones into a video baby monitor. Picture and sound go straight from one phone to the other, encrypted, and nothing gets stored.

    Cut
    The account, and the recordings that come with it. Every other app asks you to create one so the video can run through their servers. This one pairs two of your own phones, so there's no history, no clip library, and nowhere to store any of it.

    5.0 ★ · 1 rating

    BabyBeam baby unit showing the pairing code and QR code
  3. WristVault

    Watch collection · iPhone & iPad · Live

    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.

    Cut
    Half of what I'd sketched. It went to the App Store without it. What stayed: one payment instead of a subscription, while the rest of the category moves the other way. The free version holds three watches and still exports, so the paid unlock has to be worth it on its own.
  4. Stillwater

    Browser experiment · Open

    A pond in a browser tab. Skip stones across it, ring the lilypads, watch the koi. Written from scratch in WebGL.

    Cut
    Score, install, roadmap. I wanted somewhere to work on timing and weight without a store attached to it.

One case

BabyBeam: what it costs to build a baby monitor without an account.

The problem

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.

The call

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.

What it cost

  • A setup barrier Both phones need to be signed in to iCloud. Not the same Apple Account, but signed in. Every app with a cloud gets to skip that sentence during setup.
  • Connecting became the user's problem An app that routes everything through its own servers always connects, because there's only one route. Two phones finding each other directly usually works, but sometimes a mobile network gets in the way. Then you have to add a TURN relay yourself, under the gear icon. I moved a type of problem off my plate and onto a settings screen.
  • It reaches the marketing The pairing code is what keeps it secure, so it can't show up anywhere. Not even in my own App Store screenshots, which I had to redo with the code blurred.

Where it stands

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.

On AI

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:

  • GRID_BREAKER · privacy policy “No network connections, servers, or cloud services.” The game has Game Center leaderboards. The text read well and sounded certain, but it was wrong about my own app, right underneath a live App Store listing.
  • WristVault · landing page “Your collection never leaves your device.” The privacy page right below it described iCloud sync. Both sentences were meant to reassure people, but only one of them was true.
  • WristVault · call to action “Coming soon to the App Store” It was an 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.

How I work

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.

Background

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.

Contact

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.