The moment this product started was not a market analysis. It was a Sunday evening when I asked my kid a simple question — “how long were you on YouTube today?” — and realised that neither of us actually knew.

Not in a “she is lying to me” way. She genuinely did not know. Nobody knows. You open an app, three recommended videos autoplay, a short becomes eleven shorts, and the clock is somewhere behind the screen where nobody is looking. The phone’s built-in screen time told me “YouTube: 2h 41m”. It did not tell me what those 2h 41m were. Two documentaries and a music video is a different evening from ninety shorts.

That gap — time is measured, content is invisible — is the problem I decided to build for.

The category already exists, and it is crowded

I want to be honest about the market before I talk about the product, because “I found an untapped need” would be a lie.

Parental monitoring is a mature, competitive, well-funded category. There are long-established players with app stores full of reviews, enterprise sales teams, school district contracts, and marketing budgets I will never match. Some of them have been around longer than the phones they monitor. If you search for “parental control app” you will not find a vacuum — you will find a wall.

So the question was never “does this need exist”. It was: is there a version of this product I would actually be willing to install on my own child’s phone?

For a long time the answer was no.

Why the existing tools felt wrong to me

I installed several. I read their feature lists carefully, the way you read a contract rather than an ad. And the same words kept appearing:

• Stealth mode.
• Invisible installation.
• Runs hidden in the background.
• Your child will not know.
• Screenshots every 30 seconds.
• Keystroke logging.
• Read their messages.

Some of these are technically impressive. All of them are, functionally, spyware pointed at a minor. The marketing copy usually dresses it up as safety, but the mechanism is concealment, and concealment is the actual product being sold. The screenshots in the app store are of a dashboard. The thing you are buying is the child not knowing about the dashboard.

Two things bothered me about that.

The first is the obvious ethical one. A twelve-year-old has a reasonable expectation that their parent is not silently reading their private messages. You can argue the parent has the legal right. I am not arguing about rights. I am arguing that exercising that particular right, in that particular way, teaches the child exactly one lesson: the people who love you will watch you without telling you. That is a lesson with a very long tail.

The second is practical, and it is the one that convinced me. Hidden monitoring has a half-life. It works until the day it is discovered, and it is always discovered — a battery drain, a stray notification, a friend who recognises the icon, a kid who is frankly better at phones than their parents are. And on that day you do not get a conversation about screen time. You get a conversation about betrayal, and you never get the first conversation again.

A tool that self-destructs on discovery is not a safety tool. It is a countdown.

The one rule I set on day one

So before any code, before any architecture diagram, I wrote down a single product rule and made everything else answer to it:

The child always knows they are being monitored, and can see exactly what is collected.

Not “can find out if they dig”. Not “was told once at setup”. Always knows. In practice that turned into three concrete, non-negotiable behaviours in the companion app that installs on the child’s phone:

1. A permanent visible banner. The app is not disguised. It does not use a fake calculator icon. It carries a persistent “monitored by <parent name>” indicator. You cannot run Kidslen invisibly, because there is no invisible mode to run.

2. A transparency screen. Any time, without asking anyone, the child can open a screen that lists exactly what is collected: which platforms are connected, what kind of events are recorded, how long the data is kept, what the parent’s dashboard can see. Written in plain language, not a privacy policy.

3. Recorded consent at enrollment. Setup is a two-person ceremony. The child is shown what will be collected and taps to acknowledge it, and that acknowledgement is stored with a timestamp. If a parent is not willing to do that step in front of their kid, this is not the product for them — and I am fine with that.

There is deliberately no hidden mode. Not a disabled one. Not one behind a paywall or a support ticket. It does not exist in the codebase, and every time I have been tempted to add “just a low-profile option”, the rule above has said no.

What transparency cost, and what it bought

I will not pretend this is free.

It costs me the largest, most motivated segment of the market. The parent who searches for “app to monitor my daughter’s phone without her knowing” is a real buyer with a credit card out, and Kidslen is a bad answer to their search. Refusing that segment is the single most expensive product decision in this project.

It also costs capability. Once the child knows, the child can behave differently — use a friend’s phone, use the school laptop, watch on the TV. Transparent monitoring gives you an honest partial picture instead of a comprehensive secret one. I decided the honest partial picture was worth more, because the purpose was never evidence collection. It was having the conversation on Sunday evening with actual numbers in front of both of us.

What it bought is a product that gets stronger over time instead of weaker. Nothing in Kidslen breaks when it is discovered, because there is nothing to discover. The nightmare scenario for a stealth product — the child finds out — is Kidslen’s normal operating state.

And it bought a design constraint that turned out to be enormously useful. “The child can see everything the parent sees about them” is a brutal filter on feature ideas. Keystroke logging does not survive it. Silent screenshots do not survive it. Reading private messages does not survive it. What survives is a narrower, calmer product: what they watched, on which platform, for how long, and did that cross a limit we agreed on.

What Kidslen actually does

Concretely, the shape it settled into:

• A companion app on the child’s phone connects the child’s own accounts on YouTube, Netflix, TikTok, Instagram, Disney+ and Prime Video — six platforms, the ones that swallow the evening.
• It reports viewing activity — titles, platform, duration — to a backend.
• A parent dashboard shows a live activity feed, watch-time by platform and by day, and lets the parent set policies: a daily screen-time limit, a bedtime window, a blocked platform, keyword alerts.
• When a policy trips, the parent gets an alert. So does the child, in their app.
• Data can be exported in full, and deleted in full, on request, without emailing support.

That last line matters more than it looks. Data minimisation and deletion are not a compliance appendix here; they are part of the same rule. If the child can see everything collected, the child’s parent must also be able to make it all go away. A monitoring product that cannot delete its own data has not earned the right to collect it.

The differentiator was the ethics, not the feature list

I did not set out to make the ethical stance the marketing position. I set out to make a tool I could install without feeling like a hypocrite, and it took me a while to notice that this was the differentiator.

On features, I cannot win. The incumbents have more integrations, more platforms, more years, more staff. On mechanism, the gap is smaller than you would think, and I will spend the next few posts showing exactly how it works. But on stance — on being the one that will not hide, that shows the child the same data it shows the parent, that deletes everything when you ask — there is very little competition, because most of the category is built the other way round.

It also happens to be the thing that makes the product work in a house with a teenager in it. The unlock was not catching anyone. It was that the numbers became shared, visible and boring, and boring numbers are the ones you can actually negotiate with.

What this series covers

This is part one of a build-in-public series about building Kidslen. What is coming:

• Part 2 — how a technical due-diligence review of a legacy OTT analytics platform produced a catalog of about sixty concrete problems, and how each one became a design rule. The “what not to build” post.
• Part 3 — the architecture, and much more interestingly, everything I deliberately did not build.
• Part 4 — the core capture mechanism: WebView plus injected JavaScript, why it is inherently fragile, and the mitigation that keeps it alive.
• Part 5 — building four applications in parallel with AI agents against a single written API contract, and what I had to verify by hand.

I will be honest about the bugs, including the ones I shipped. A product whose entire premise is trust does not get to have a tidy build log.

If you want to see what the finished thing looks like, it is at kidslen.app.