Every book, class and app in pregnancy is aimed at her. The partner is handed a due date and told to be supportive. BirthCrew gives him the other half: what is happening this week, what she has actually asked for, what to do in the room, and a check-in that nobody else ever sees.
Client
BirthCrew
Year
2026
Role
Product design · Full stack
Stack
Next.js · Supabase
Any given week
WEEK 36
4 weeks to go
WORTH DOING
Fit the car seat
WHERE SHE IS UP TO
Third trimester checks weekly
One thing worth doing this week, and where she is up to. It asks him for one action, never a list.
Labour mode
Everything else
This weekWeek 39 · 4 days to go
Worth doingFit the car seat
Her plan6 preferences recorded
Hospital bag9 of 12 packed
Check-inLast answered Tuesday
Tap Labour starts, and watch what the app takes away.
Watch it work
The problem
The non-birthing partner is the only person in the room nobody is briefing. He is expected to advocate for her during the most consequential hours of her life, having been told roughly nothing, about a plan he has never read. So he stands at the end of the bed being useless, and both of them feel it.
What I built
A product that treats him as someone with a job rather than a bystander with a phone. It holds her stated preferences so he can speak for her when she cannot, gives him something concrete to do each week, and puts the things that help in the room one tap from the screen he is already on.
Two states of the same product. The left is any given week: how far along she is, one thing worth doing, and the reason it matters. The right is labour, where the interface drops to a timer, the name of the person to ring, and 000, because at three in the morning, anything else on screen is a thing to get lost in.
Her words, not advice
the plan captures what she has asked for and never recommends a clinical option. The midwife and hospital decide what is meaningful
No score, no label
his weekly check-in returns no number and no diagnosis, because a score is a thing to argue with rather than answer honestly
Data stays in Australia
stored in Sydney, exportable and deletable, with no third-party analytics sitting on top of it
Her plan, in his pocket
HER BIRTH PLAN
READ ONLY
She writes it, he carries it. He gets a read-only link, so he can see it and cannot quietly edit it into something she did not ask for.
Answers, never a score
WEEKLY CHECK-IN
Six plain questions, and no score at the end. A number would invite him to pass or fail at being worried.
So he can speak for her
A birth plan is usually a document she wrote and he skimmed. Here it is four short sections he fills in with her, summarised back so the answer is legible at a glance in a room where nobody has time to read. She gets a read-only link. She can see it, and he cannot quietly edit it into something she did not say. The product captures preferences and never generates a recommendation: every screen carries the same line about education, not medical advice, and that constraint sits in the schema rather than only in the copy.
The bit that is only his
Supporting someone costs something, and the person doing it is usually the last to be asked about it. The weekly check-in is six plain questions with no scoring, no band and no clinical label. Answers are stored, shown back as what he wrote and when, and read by nobody else. Where a pattern suggests it, the app quietly surfaces PANDA or Lifeline instead of returning a result.
The honest bit
These screens are a seeded demo account. The partner, the dates and every answer on them are invented, because the real content of this product is somebody’s pregnancy and it does not belong in a portfolio. There are no usage numbers here either. It has no users yet, and a health-adjacent product is the last place to invent traction.
Got a product where the person nobody designs for is the one who decides?