Citylore: on-device facial recognition for a wellbeing habit.
A wellbeing app built with Python, Django, Django REST Framework, React and React Native, based on the mental and physical benefits of smiling. It uses facial recognition to register the act itself and tracks progress over time — a small behavioural idea that puts an unusually sensitive technology at the centre of the product.
The challenge.
- The core interaction depends on facial recognition, which is among the most privacy-sensitive technologies a consumer product can use, for a purpose that is deliberately lightweight.
- Recognition had to work across the range of faces, lighting and camera quality real users bring, not the narrow conditions a demo is filmed under.
- The value only appears through repetition, so the daily interaction had to cost the user a few seconds and no more.
- Progress tracking needed to feel encouraging rather than judgemental — a wellbeing product that makes users feel monitored defeats its own purpose.
Our approach.
- Ran facial detection on the device and transmitted only the resulting event, never the image. A wellbeing app has no reason to hold a library of users' faces, and the cheapest way to protect biometric data is to never collect it centrally.
- Kept the server model in Django deliberately thin — occurrences and progress, not imagery — so the sensitive data never enters the backend's threat surface at all.
- Built the client in React Native so the camera interaction behaves consistently across platforms, with a React surface for the wider progress views.
- Tuned detection sensitivity toward accepting genuine attempts rather than rejecting marginal ones, because a false rejection in a habit product costs a user's engagement while a false acceptance costs almost nothing.
- Designed streaks and history to show accumulation rather than failure, avoiding the punitive framing that causes users to abandon habit apps after the first missed day.
The outcome.
- The biometric interaction never leaves the device, so no facial imagery is stored server-side.
- The daily interaction is short enough to survive as an actual habit.
- Detection tolerates ordinary conditions rather than requiring ideal ones.
- Progress is presented as accumulation, which is what keeps people using a wellbeing product.
Related healthcare & life sciences work.
HealthcareFitmesh: workout, diet & social fitness.
One app replaces three for serious users.
React Native · Django · Django REST Framework · PostgreSQL
HealthcareWellthread: shared health records, plans and progress.
A web app for health & wellness, built with Google Cloud Functions. Records, plans and progress stay consistent between the user and whoever supports their care, in a product simple enough for daily use.
Google Cloud Functions
HealthcareSwiftcart: Health platform.
A web app for health & wellness, built with Flask and Python. Records, plans and progress stay consistent between the user and whoever supports their care, in a product simple enough for daily use.
Flask · Python
Where AI fits in healthcare & life sciences.
Drafting letters and summaries for clinicians to approve, patient assistants that know when to hand over, and retrieval over guidance documents, built with UK GDPR and clinical safety in mind.
Explore AI developmentQuestions about this build.
Still wondering something? Ask an engineer
Run detection on the device and send only the derived event. The application needs to know that something occurred, not what the user's face looks like, so the image never needs to leave the phone. This removes the biometric data from your backend threat surface entirely, which is both the strongest privacy position and considerably simpler than securing that data centrally.
Make the core interaction very short and make the feedback additive. Habit products fail on two things: an interaction that takes long enough to be skipped on a busy day, and progress framing that punishes a miss and gives the user a reason to stop entirely. Showing accumulated progress rather than broken streaks keeps people returning after an interruption.
Test against the conditions users are actually in — varied faces, poor lighting, older devices, imperfect camera angles — rather than the controlled conditions of development. Then tune the threshold according to the cost of each error type. In a wellbeing product a false rejection frustrates a user into leaving, while a false acceptance costs essentially nothing, so the tuning should be permissive.
Start by minimising what you collect, because data you never hold cannot be breached, subpoenaed or misused. Beyond that: be explicit about what is stored and where, keep retention short and actually delete rather than hide, and avoid third-party analytics that would carry health-adjacent signals off your infrastructure. Consumer health products often sit outside strict clinical regimes, which is a reason for more care rather than less.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.