Thirteen open blockers, one shippable V1.
DadWell is a wellbeing app for new and expectant fathers. I took it from an unbounded scope and a legal minefield to a locked V1 on a date, closing the blockers one at a time and putting an owner against every deferred item.
Role
Product and delivery lead
Timeline
2026
Team
A product owner and two app developers, run by me
Live
dadwell.app ↗
01
The problem
DadWell had a clear reason to exist and no boundary around it. The founder wanted an app that supported fathers through pregnancy and the first year, and every conversation added something: mood tracking, community, weekly guides, a partner account, an EU launch.
Underneath that sat a harder problem nobody had costed. The product handles health data about a pregnancy, has a community feature, is sold on subscription and was heading for two jurisdictions at once. That's a stack of legal obligations, and none of them had been written down.
02
What I did
I turned the compliance risk into a document before it became a delay
I wrote up every legal and technical blocker as a numbered list with an owner and a decision needed, and took it to the founder as a deck rather than a conversation. There were thirteen items, each one fact-checked against the primary source rather than a summary, which caught three of my own claims being wrong before they reached him.
I cut the EU out of V1
Shipping into two jurisdictions doubled the compliance work for a product that hadn't proven anyone wanted it. I proposed UK only for V1 and moved the EU into V2. It was the single decision that made the launch date real.
I kept the change request honest, including the parts that were already ours
When the founder asked what the extra work involved, the admin panel and the moderation work were already inside the agreed scope. Leaving them in the change request would have inflated it. They came out, and what went back was smaller than it could have been. Scope discipline runs both ways, or it isn't discipline.
I designed the launch offer as a product decision, not a discount
Founding 500 runs at £49.99 a year with fifteen months for the price of twelve, no free trial, and a fourteen day refund by email. Leaving the trial out was deliberate, because a trial on a subscription this cheap costs more in churn admin than it wins in signups.
The scope did not shrink because we designed faster. It shrank because we decided what not to build.
03
How I ran it
I ran this with a product owner and two app developers, and it held together on two habits. The board got reshifted every Monday, so the week started with an agreed order rather than an argument about one. Every Friday one written update went out in the same four parts: shipped, next, need from you, at risk.
Written updates beat calls here, because a template can be filled in by whoever actually did the work, and because “at risk” is far easier to write down than to say out loud on a call. It's also the line that saved the launch date. The EU question sat under it for three weeks before we agreed to cut it.
The thirteen blockers each carried an owner and a date, and none of them was allowed to close until the answer was written down.
04
The journey
A father arrives tired, so the product asks for as little as possible before it gives him something back. Onboarding takes a name and a stage, expecting or new dad, and asks for consent on its own screen rather than burying it in a tick box. From there the home screen carries one thing to do today and where he is in the forty weeks.
Everything else hangs off four places. The weekly guide is the spine, with one entry for each of the forty weeks. The daily check-in is the smallest input I could design, a single tap on whether it was a good day, an okay one or a hard one. The library holds the guides he can reach for out of sequence. The community is the one place other fathers appear, and it's moderated, because an open feed on a wellbeing product is a liability rather than a feature.
Settings is where the compliance work surfaces as product rather than as a policy page. Consent management, privacy rights and notification control are screens a father can actually reach and change. Behind all of it sits the admin panel, so the team edits guides, resources and moderation without a developer in the loop.
05
What shipped
V1 was locked and handed over build ready, carrying onboarding, weekly guides across forty weeks, the subscription paywall, the notification set mapped to the admin panel, and a moderated community, each one specified against the blocker it closed. The product site is live at dadwell.app and the build sits with their team.
06
Impact
User states in V1, expecting and new dad
2
Open blockers at scope lock
13 to 0
Markets in V1, with the EU deferred
UK only
Weekly guides written for V1
40
07
The work
The states first, because that is where the work is. Then consent and the privacy rights, written to be used rather than agreed to. Then the app itself, the home screen, the forty week calendar, the guide library and the community, with the admin panel and its preview behind them. Then the system underneath it all.
08
Go deeper
Design system and Figma
The tokens are semantic and bound throughout rather than hardcoded, so a colour change propagates instead of needing a sweep. Light and dark are built at section level. The brand font couldn't be written through the API, so the swap runs through a plugin workaround that is documented for whoever picks the file up next.
Build and handover
It's a Flutter app on a custom web CMS rather than an off-the-shelf one, which we chose after a build-versus-buy comparison, with RevenueCat for subscriptions and an admin panel for content and moderation. The notification set was specified as a developer-ready document, with each one drawn on a real lock screen so there was nothing left to interpret.
More
All work
→
