Sheyna: Hebrew sleep accompaniment on WhatsApp
A Hebrew service that walks a parent through ten nights of sleep foundations, delivered entirely in WhatsApp. Scripted onboarding she taps rather than types, a safety classifier in front of every reply, and a nightly loop of evening check-in and morning debrief. Built solo and shipped, with seven eval suites that block any deploy.
The product is public: sheyna.vercel.app
Family conversations are private and stay private. Everything below is architecture, safety design, and economics.
Problem
A parent of a six-month-old does not lack advice. Advice is everywhere, it contradicts itself, and it arrives at 3pm when the hard part is 3am. What is missing is accompaniment: someone who knows this baby's nights, remembers what was tried yesterday, and answers now. Consultants provide exactly that and are priced accordingly. Everything cheaper is a static PDF.
It had to be in Hebrew and it had to be on WhatsApp, because that is where an Israeli parent already is at 3am. Not a new app to install with one hand.
The two boundaries the product is built from
Before any architecture, two lines were fixed and are never crossed: zero medical content and zero harm. The system does not diagnose, does not interpret a symptom, and does not offer anything that could be mistaken for medical advice. Anything touching a baby's body leaves the product and goes to a human.
That is not a disclaimer bolted on at the end. It is the reason the architecture looks the way it does, and it made the system far simpler to reason about than a triage tool - because there is no triage. There is one question: is this ours to answer at all?
Why a classifier in front, not a careful prompt
A system prompt asking a model to avoid medical advice is a request. A classifier that runs first and gates the reply is a control. The difference matters when the subject is an infant.
It fails closed: an error, a timeout, or an answer it cannot parse is treated as a hit, and the parent gets a handoff rather than a guess. The operating rule is deliberately asymmetric - when in doubt, flag. An unnecessary handoff costs a little warmth. A miss costs something that cannot be repaid.
Scripted, not generated
Onboarding is a script with tappable buttons, not a conversation with a model, and every answer has a reply written for it in advance - so warmth costs nothing at runtime. The age gate is deterministic rather than inferred: the full programme above six months, an education track below it, and an honest refusal younger than that instead of a guess.
The model is used only where it earns its place - the safety classifier, the personalised read, the plan, and live coaching. Everything else is code.
The parts that are not the happy path
- Evals block every deploy. The safety charter is not prose - it is the classifier's specification and the source of the blocking suite.
- Leaving works from anywhere in the conversation, and cancelling is a request with a confirmation step that can be walked back. A door that only opens one way is a bug.
- Deletion exports before it erases, and refuses to erase if the export fails.
- One flag rolls the whole thing back in about a minute.
- Language is eval-enforced. Hebrew terms that read as harsh or clinical to a local parent are banned in the product's own voice, and the tests fail if they appear.
Outcome
A shipped Hebrew service on WhatsApp: scripted onboarding, a gated safety path, a ten-night programme that changes one thing at a time, and a daily loop that asks rather than waits.
What it demonstrates: designing an AI product where the hard constraint is what it must never say, turning that constraint into an executable specification, and keeping the model out of every place a script does the job better.