---
title: "A personal journal on WhatsApp: what an MVP that collects sensitive data really needs."
url: "https://simonebova.com/en/runs/startup-wellness"
lang: "en"
author: Simone Bova
alternates:
  it: "https://simonebova.com/md/it/runs/startup-wellness"
  en: "https://simonebova.com/md/en/runs/startup-wellness"
  pl: "https://simonebova.com/md/pl/runs/startup-wellness"
---

# A personal journal on WhatsApp: what an MVP that collects sensitive data really needs.

A WhatsApp journal I built alone in five weeks. The choices that protect very personal data without turning an MVP into a final architecture.

Name: Wellness startup

Terrain: AI-native startup · wellness

When: 2025

Role: Sole developer, requirements to handover

| Fact | Value |
| --- | --- |
| Terrain | Startup |
| Time | Five weeks |
| Team | Simone Bova |
| Personal data | Encrypted |

## The situation

An AI-native wellness startup wanted a journal that lived inside WhatsApp. During the week the user sends messages and voice notes, and on Friday they get a personal report. No app to install, very intimate data, an MVP budget. There were two risks to avoid: losing something a person had trusted the journal with, or exposing it.

## What I did

I did all of it alone, from requirements to the handover document, in five weeks. The rule I set myself was simple: first make what the user wrote safe, then do everything else. Transcription, analysis and reports run afterwards, in separate stages, and each one can restart on its own if something goes wrong.

On the data side I encrypted everything personal, phone number included, without losing the ability to recognise someone who writes again. And I kept the architecture small: one service fewer whenever I could, with one clear place in the code from which to swap it later.

## What changed

The client received a product ready to launch and a handover document that says what can break, what is left to do before launch and how to bring the system back up. The known technical debt is written there, next to the architecture. The system is built so that a voice note sent on Tuesday reaches Friday's report even if a stage jams in between.

## What I learned

The phone number was the only identity the journal knew, and also one of the things most in need of protection. Plain text was out of the question. Encrypting it and nothing else meant decrypting every number on every incoming message just to work out who was writing. That's where I saw that protecting a piece of data and finding who it belongs to are two separate problems. I kept two versions of the number: an encrypted one for when it's really needed, and one that can only recognise someone writing again. I treat the second as personal data too.

In the journal the encryption keys live outside the database, by design. I wrote the consequence plainly in the handover document: a database restored without its keys is unreadable. A successful backup feels like the power to bring the product back, and here, on its own, it brings back nothing. So database and keys are recovered through two different procedures, held by two different custodians, and the document asks for a full restore test before launch. Since then I count a backup plan for encrypted data as verified only after a restore that reaches readable data.

The product promised a personal report every Friday. Written as an instruction to the model, “summarise the week” left open the questions a user eventually asks: which week, in which time zone, with which messages, whether a voice note transcribed late belongs in it, and whether “ready” means “delivered”. No prompt answers those. Here every report knows which messages it came from, what period it covers and what state it's in. Since then I define a periodic report before writing its prompt, so that months later anyone can still explain what a specific report summarised.

[Runs](https://simonebova.com/md/en/runs)

[simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)