The Business Challenge
The business situation the organisation faced before the project began.
After a breakup, the riskiest moment is the impulse to text an ex: usually late at night, alone, with nobody to talk to. General chatbots need an account, take time to open and keep the conversation. The goal was a one-tap intervention inside a daily health app people already open, that reads the person's own journal (mood, urge to text 1-10, whether they checked the ex's feed), answers in seconds in their language, stores nothing, and is never unsafe for someone in crisis.
Why AI Was the Right Solution
Why AI was the right approach — and what alternatives were considered.
A rules engine can flag keywords, and a static library can tell someone to breathe, but neither produces the one sentence that lands: advice that quotes the user's own numbers (an urge at 8 out of 10, at midnight, after four clean days) and names one specific action for the next ten minutes. That specificity is language generation conditioned on the user's own data, which is exactly the narrow task the model was given. Off-the-shelf wellness apps fail in the other direction: generic content gets ignored by the third read.
How the Solution Was Delivered
Discovery, design, development, testing and rollout — the journey, not the tooling.
- 1Mapped the failure moment: late-night urge spikes, when friends are asleep and generic advice is useless.
- 2Built the app as one offline-first file with versioned local storage, so no update could lose a journal entry.
- 3Defined the AI boundary first: what leaves the phone, how much, and what never does.
- 4Put a Cloudflare Worker in front of the model for origin allow-listing, per-IP rate limits and payload caps.
- 5Added bilingual crisis screening ahead of the model, routing self-harm language to hotline guidance.
- 6Tuned the system prompt to a hard word cap and a rule to quote the user's own numbers.
- 7Fixed a language-leak bug by rendering the journal in the user's language before prompting.
- 8Ran 17 releases against 35 automated journey and promise checks, with one rollback.
Key Technical & Architecture Decisions
Architecture, model selection, workflow and trade-offs.
Single-file PWA instead of a framework app: installable, works offline, no build step. The trade-off is manual discipline as the file grows.
Cloudflare Workers AI (Llama 3.3 70B with a fallback model) instead of a browser-exposed API key: the key never reaches the client, latency stays at the edge, and nothing is retained server-side.
Send only the last 14 journal days plus the chosen language: enough context for specific advice, small payload, bounded privacy exposure.
Sign every request with an origin-bound HMAC and reject unsigned or stale calls: the published app works with no pairing code, while a re-hosted copy gets 403.
Screen for crisis language in code before the model, not in the system prompt, because a prompt is a request rather than a control.
Passkey lock and encrypted multi-device sync: a breakup journal is data people do not want sitting in a password database.
Challenges & How They Were Solved
Obstacles hit along the way and how they were overcome.
The hardest problem was not the model but the boundary around it. A public single-file app can be copied in seconds, so the endpoint had to accept the real app and refuse everything else; solved with a per-request signature covering timestamp, origin and body, plus an origin allow-list, six requests per minute per IP and a payload cap on the Worker.
The second was language drift: Chinese replies picked up English labels because the journal was rendered in English before prompting. Rendering in the user's language first fixed it.
The third was schema change: five data versions shipped in one week, each with a migration that preserved existing records, plus one rollback after a regression.
Safety tuning was its own loop: the crisis screen intentionally favours recall, and false positives fall back to supportive guidance instead of a model call.
User Adoption & Change Management
How users responded — training, change management and feedback loops.
This is a personal product, so adoption started with me: I used every version daily and shipped only after the automated journey checks passed. That changed how I would run rollout with a team. The AI-off switch is what made daily use feel acceptable, because it turns a privacy promise into something a user can verify with one tap. Trust in the coach itself came from constraints: replies capped at 70 words and required to quote the user's own numbers. The first version that stopped sounding like a chatbot was the one that got opened on consecutive days.
Business Outcomes & Impact
The measurable outcomes from the underlying AI Deployment — with the story behind them.
AI reply latency ~2-4 s; app quality score 95/100; 33 of 35 automated journey/promise checks proven; 100% of self-harm-language entries routed to hotline guidance instead of the model (by design and tested)
Business Outcome Categories
The story behind the numbers
This is a personal product, so impact shows up in one person's week rather than a company P&L, and the figures are what I instrumented: AI replies land in about 2-4 seconds, so the coach arrives while the urge is still rising rather than after it has passed; the published app scores 95/100 on CloudCrane's automated quality check; and 33 of 35 journey and promise checks are proven by automated tests. The outcome I care about most is guaranteed rather than measured: every entry containing self-harm language is routed to hotline guidance instead of a model reply, which keeps the highest-risk conversations out of the LLM entirely.
Lessons Learned
What surprised the team, what worked well, and what would be done differently.
- The crisis gate belongs in code, not in the system prompt.
- Ship the data migration with the feature, not after it.
- Measure latency and refusal behaviour, not only how good the prose reads.
- Privacy controls are adoption features when the data is personal.
- A signed, origin-bound request path is the difference between a demo and something you can publish.
Future Opportunities
Where this solution could go next.
On-device model fallback so the coach can answer with no network at all.
Weekly pattern summaries (stress timing, urge timing, hydration) generated locally, with the AI limited to explaining a trend the user can already see.
A clinician-reviewed crisis resource set per region instead of one hotline list.
Scheduled follow-ups: after a high-urge entry, a check-in ten minutes later and again the next morning.
Professional Reflections
Guidance for another builder tackling a similar problem.
Decide the boundary before you write the prompt. The questions that mattered were: what leaves the device, how much of it, for how long, who can call the endpoint, and what happens when the model is wrong. Everything else was prompt iteration. Also budget real time for the boring parts, because data migrations, rollback plans and tests that prove a safety rule still fires are what let you publish something that touches someone's worst week.