On-Device Wellbeing Journal with Private Mood and Sentiment Trends

The problem with mood tracking apps

People write their most private thoughts into journaling and mood apps. Mozilla's Privacy Not Included research found that many popular mental health and prayer apps track and share users' intimate data, and that privacy policies are often worse than users assume. There is no technical need for this: a phone today can store encrypted text and run a small language model locally. What is missing is an app that is built around that fact and can prove it.

What already exists and the gap

• Daylio is a mood tracker that stores data locally on the phone with optional backups to the user's own cloud storage. It relies on mood icons and activities rather than analysing free text.
• Stoic is a journal with prompts and AI features; some processing runs on-device on Apple devices, but privacy options differ by platform and plan.
• Day One is a polished journal with encrypted sync, built for writing rather than mood analysis.

The gap is a journal that analyses free-text entries for sentiment and emotion entirely on the device, encrypts everything at rest, and ships with evidence, not just a policy, that nothing is transmitted. It is the same design principle behind Apple's and Google's push for on-device ML: the most sensitive data should not need a server.

What you build

One user, one device:

• Write entries with optional mood, activities and sleep tags.
• Each entry is classified on the device for sentiment and a small set of emotions.
• A weekly and monthly view shows trends and which tags co-occur with better or worse days.
• The app is locked by passphrase or biometrics and the database is encrypted.
• If an entry contains defined crisis phrases, the app immediately shows local support resources.

The technically interesting part

The privacy architecture and its proof. Derive or protect the database key with the platform keystore, encrypt with SQLCipher, and ensure the model and all assets ship in the app so there is no network call at all. Then prove it: route the phone through mitmproxy and capture traffic during a full session, including first launch. A verified claim is worth far more than a stated one, and the verification method is a contribution in itself.

The accuracy trade-off. On-device models are smaller and less accurate than server models. Label a test set (a public emotion dataset plus a small set of your own, written for the purpose, not real users' diaries), and compare your quantised model against a larger reference model run offline on a laptop. Report the gap and argue whether the privacy gain is worth it.

How to evaluate it

• Network evidence: traffic capture showing zero requests during a scripted session, with the method described so others can repeat it.
• Model quality: accuracy and F1 per class for the on-device model versus the reference, on the same test set.
• Performance: inference time per entry and app size on a mid-range Android phone.
• Crisis handling: a test list of phrases, including tricky negatives, with expected behaviour, all passing.
• Usability: 6 to 8 participants use it for a week; report whether they trust the privacy claim and why.

Suggested plan

1. Weeks 1 to 2: review privacy research and competitors; write the threat model and the ethical boundaries.
2. Weeks 3 to 5: encrypted storage, lock, entry editor.
3. Weeks 6 to 8: model selection, quantisation, on-device inference, test set.
4. Weeks 9 to 11: trends, tags, crisis handling, in-app privacy page.
5. Weeks 12 to 15: traffic capture, model comparison, user week, write-up.

Path to a product

Privacy-conscious users do pay for tools they trust. A one-time purchase or a small yearly fee for extras such as encrypted export and themes fits better than ads, which would contradict the whole design. Open-sourcing the app builds trust and is a strong portfolio signal for mobile and privacy engineering roles. A later version could be offered to university counselling services as a private tool students keep for themselves, never a monitoring tool.

Scope warning

This is a journal, not a mental health intervention. It must not diagnose, score anyone against a clinical scale, or imply treatment. Crisis handling must be designed, tested and described in the report, and if your institution has an ethics process, this project goes through it. No social features, no sharing, no cloud backup by default: every network feature undermines the project.

Learn what you need on Sefism

• Mobile roadmap : Flutter, secure storage and platform APIs.
• Machine learning roadmap : classification, evaluation and model compression basics.
• Machine learning cheat sheet : precision, recall and F1 for your comparison.
• OWASP Mobile Application Security (MASVS and MASTG) : storage, crypto and network testing guidance.
• Android Developers: Develop for Android : keystore and on-device ML documentation.

Get help with this idea

Supervisors respond well to a privacy claim backed by evidence, so bring your traffic capture plan and your crisis-handling design early. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session