Dad & Baby is a free UK pregnancy and early-parenting companion, built specifically for fathers. It covers the journey from positive test through to the toddler years, with NHS-aligned tools and a deliberately dad-first information design.

The pregnancy app, built for dads.

Audience

UK fathers — expecting, brand new, or in the early parenting years.

Distribution

iOS App Store and Google Play. Web access is gated to native only — desktop browsers are redirected to a download page.

Business model

Freemium. Core features and content are free. DadPro is the £4.99/month subscription that unlocks the daily baby tracker, anonymous forum, dark mode, partner sharing, data export, and removes ads.

Promise to the NHS

Free for dads. No cost to the NHS.

The product is a single Next.js codebase that serves both the marketing site and the gated app, wrapped in a Capacitor shell for the App Store and Play Store builds.

The Capacitor mobile app is a thin native shell — its only job is to embed a WebView and point it at https://app.dadandbaby.co.uk. UI and JavaScript changes ship via git push to Vercel — no AAB or IPA rebuild is needed for product changes. Only native plugin upgrades, splash or icon changes, or capacitor.config.ts changes need a fresh native build.

The single most important architectural choice in this project lives in capacitor.config.ts:

{
  appId:   "co.uk.dadandbaby.mobile",
  appName: "Dad & Baby",
  webDir:  "out",
  server: {
    url:       "https://app.dadandbaby.co.uk",
    cleartext: false,
  },
  plugins: { /* push, splash, status bar */ },
}

server.url makes the native binary a thin shell that loads the production Vercel build. Most product changes never touch the native projects at all. The things that do require a fresh native build are exactly the things you'd expect:

• Bumps to any @capacitor/* plugin version
• New native plugins added to capacitor.config.ts
• Splash, icon, or status-bar config changes
• Android / iOS metadata (Play Store data-safety, App Store privacy)
• Native code under android/app/src/main or ios/App/App

The cost of this convenience: you can break v1.0 of the app for installed users by deploying a bad web build. There's no version pinning per native release — every native install always points at the latest deployed Vercel app.

The same Vercel deployment serves two distinct surfaces, routed by host header:

Two independent gates

Web access to the app is blocked for desktop browsers via two independent layers — server-side for primary protection and client-side for safety:

The middleware is the primary gate; MobileGate is the in-app safety net for the edge case where a mobile UA gets through but it's not actually the native shell (e.g. someone opening the URL in mobile Safari).

Three sign-in methods, all funnelling through Supabase Auth. Sessions live in HttpOnly cookies, refreshed on every request by the middleware.

Email OTP

8-digit code emailed to the user, verified via supabase.auth.verifyOtp. The primary path — no passwords to remember.

Apple Sign-In

@capgo/capacitor-social-login returns an ID token → supabase.auth.signInWithIdToken. Refresh tokens are stored in a custom table so the apple-link edge function can revoke them on account deletion (Apple's required deletion behaviour).

Google Sign-In

Same plugin, same flow. The friction-free path for users already on Gmail.

Onboarding — 7 steps

Captured once on first sign-in. A Postgres trigger creates the profiles row; the dashboard checks onboarding_complete and redirects incomplete users back to /onboarding.

1. Dad's first name
2. Stage — Expecting, Born, or Planning
3. Baby count — single or multiples (expecting only)
4. Due date or birth date
5. Birth details — weight, gender (born only)
6. Existing children (optional)
7. Terms acceptance

The schema lives in supabase/migrations/ — forward-only, 32 numbered SQL files telling the story of how the product evolved. Every user-data table has Row-Level Security, with the canonical policy "user can read or write rows where user_id = auth.uid()".

Key tables

• profiles — one per auth user. is_pro, pro_expires_at, active_child_id, onboarding_complete, accepted_terms, theme, forum_alias, stage.
• children — name, due_date, birth_date, is_born, gender, birth_weight_grams, display_order.
• appointments — typed (scan / midwife / antenatal / gp / other), child-linked, dashboard-surfaced.
• birth_plans — wide row of jsonb columns, one per birth-plan step.
• contraction_sessions + contractions — labour timing with 3-1-1 detection.
• dad_checkins / partner_checkins — date-unique mood logs.
• forum_posts / _comments / _upvotes / _reports — DadPro community with moderation.
• sleep_logs, nappy_logs, feeding_logs, activity_logs, medication_logs, illness_logs — daily tracker (Pro).
• apple_refresh_tokens — stored for required-on-deletion revocation.

The migration that mattered most: 029

Built out across pregnancy, early parenting, and post-birth — every feature anchored in NHS guidance where it applies.

The main /dashboard route reads profiles.stage and renders one of three sub-dashboards. The information density, layout, and even the colour cues shift to match where the user is in their journey.

Freemium. Core content stays free; DadPro at £4.99/month unlocks the tracker, the forum, dark mode, partner sharing, data export, and removes ads. The promise to NHS partners is "Free for dads. No cost to the NHS."

The webhook → entitlement flow

1. User completes a purchase via the native RevenueCat paywall
2. RevenueCat fires the revenuecat-webhook (verified by shared secret)
3. The function updates profiles.is_pro = true and pro_expires_at
4. On the next request, the client reads the fresh profiles row and the Pro experience activates

On warm app open, the client fires /api/pro/sync which reconciles is_pro against the user's RevenueCat entitlement — covers reinstalls, backup restores, and device migrations where the webhook never re-fired.

AdMob

Banners on a subset of free-tier screens; interstitials with a minimum 10-minute cadence (was 3 minutes, raised after certain Android creatives caused issues). ATT (App Tracking Transparency) is requested contextually before the first ad is shown — never on launch.

A strict baseline on every response, RLS everywhere, and a paranoid stance on what gets written to the client bundle.

Defended

• Strict CSP — self-only by default, Supabase for REST + WSS, YouTube-nocookie for the week-by-week videos, frame-ancestors 'none', object-src 'none'
• HSTS preload, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin
• Permissions-Policy: camera off, microphone off, geolocation self only
• COOP / CORP: same-origin
• Console stripping in production builds — only console.error and console.warn survive, so auth tokens can't leak into release WebView logs
• RLS on every user-data table, hardened in migrations 028 + 029
• Account deletion via dedicated edge function — cascades the auth user, all related rows, and revokes Apple refresh tokens
• All data in EU Supabase region; privacy enquiries to privacy@dadandbaby.co.uk

Beyond the app itself, the project carries an entire pack of partner-ready collateral baked into the repo. Brand-aligned HTML assets, rendered to PNG by a Puppeteer script that ships in the codebase.

Other collateral lives alongside it: the A5 leaflet (front + back), the NHS partnership one-pager, the Innovate UK and CFI funding appendices, the security one-pager for IT teams, the Play Store feature graphic, Instagram-format posts, and the double-opt-in waitlist email template. Everything brand-aligned, all checked into the repo.

The things that nearly broke the app — and a few that did, before we learnt about them.