HeyHugo

Leaving your child with someone is not a booking problem. It is a trust problem that happens to end in a booking. Every Danish parent solves it the same way — a sister, a neighbour, a name passed around a class group — and the moment that network is unavailable, there is nothing underneath it.

HeyHugo is the layer underneath. Families find a vetted babysitter and book her in minutes; babysitters get real employment, with a contract, a payslip and holiday pay, rather than cash in an envelope. The marketplace is the visible half. The half that makes it work is everything a parent never sees: criminal record and child-protection certificates, a signed employment contract, payroll filed with the tax authorities.

I founded it and I design and build it — the product strategy, the interface, the design system, the apps, the back office, and the database underneath them.

A parent opens the app in a narrow, bad moment: something has come up, the evening is already complicated, and the decision has to feel safe in under a minute. A babysitter opens the same platform in an entirely different frame — she is applying for a job, and the flow she meets is closer to onboarding at an employer than to a listing site.

So the product carries two rhythms on one foundation. The family side is quick, warm and low-friction. The babysitter side is patient and explicit: it tells her what happens next, what is still missing, and why we are asking for something as sensitive as a national ID number. Both sides speak Danish, in plain words rather than legal ones, because the day-to-day language of childcare is not a legal register.

One token set drives all of it. Colour, type, spacing and status language live in a shared package that the apps, the back office and the marketing site all read from, so a status pill means the same thing whether it is on a phone at a kitchen table or on a laptop in the office.

The hard part of an operations product is not the screens — it is that the same rule gets decided in several places, and the copies drift apart. Whether a babysitter may be approved, whether her certificates are in order, whether an account may be deleted: each of those answers lives in exactly one place, and the screens ask that place rather than deciding for themselves.

Where a rule cannot be trusted to the interface, it sits in the database itself. Approving a babysitter whose background check came back with a remark is not blocked by a disabled button — it is refused by the database, so the rule holds whether the request came from the web, from the admin phone app, or from something written next year.

The stack is deliberately small and modern: React Native through Expo for both apps, Next.js for the web and back office, Supabase for Postgres, authentication, storage and an encrypted vault. Schema changes are written by hand as reviewed migrations, because a childcare database is not a place for a migration nobody read.

The product handles the most sensitive data a Danish consumer product can: national ID numbers, criminal record certificates, children's names and home addresses. That shaped the design more than any visual decision did.

A national ID number is encrypted in a vault, readable only by the narrow paths that genuinely need it, and deleted automatically the moment it has served its purpose — at the signature on the employment contract, not a day later. Background checks are never stored as documents. The product keeps the date and the outcome, which is what the guidance says to keep and nothing more.

The opposite constraint applies to money. Danish bookkeeping law requires five years of financial records, so deleting a person deliberately leaves the accounting trail standing while the human disappears from it. Getting both halves right — erase the person, keep the ledger — is most of what account deletion actually is.

Every piece of work runs the same loop: a written spec that argues for a decision, a plan broken into small reviewable steps, then implementation with a review at each step and a broader review before anything merges. The specs are kept in the repository next to the code they describe, so the reasoning survives longer than the memory of it.

That process is not ceremony. It is what catches the expensive things — the rule that existed in two places and disagreed, the payroll job that could have filed the same employment twice, the change that would have deleted a national ID number a step too early. Each of those was found by review before it reached a family or a babysitter.

The same discipline shows up in the small decisions: what a screen says when something is stuck, whether a button promises something the system cannot deliver, and whether an admin is told what to do next or simply told no.

Built from an empty repository, solo, since May 2026.