A Social Accountability Platform for Health and Weight Management

Delivered remotely for a business based in Brussels, Belgium. Names withheld by agreement.

Project Overview

Industry: Health, wellness and behaviour change — weight management and healthy eating.

Type of solution: A cross-platform mobile application over a REST API with a full administrative back office and a progressive web app, built around real-time group interaction.

Business context: The weight-management app category is enormous and its retention numbers are terrible. The reason is structural rather than cosmetic: logging a meal into a database has no consequence, so the habit has nothing holding it in place. Within a few weeks the logging stops, and a tracking product with no data is a product with no value. Any serious attempt at this category has to solve adherence first, and features second.

General users: Members working on weight or eating goals within small closed groups, and the platform's administrative team managing users, groups and content.

General purpose: To make adherence social — so that logging a meal is visible to people whose opinion matters, progress is compared openly, effort is recognised, and going quiet is noticed.

The Business Challenge

Self-tracking does not survive contact with real life. Recording meals is tedious and privately unrewarding. Without an external consequence, adherence declines steadily from the day of installation.

Small groups die quietly. Group-based engagement works only while the group is active. One or two people going silent is usually enough to end the whole group's activity, and a dead group is worse than no group.

Feedback has to be immediate. Posting a meal and receiving a reaction an hour later is not accountability, it is correspondence. The social loop only works if it closes quickly.

Competition must be fair and correct. Leaderboards and achievements are visible to peers, so an error is not a bug report — it is an embarrassment in front of people the user knows. Derived metrics have to be right.

Missing data breaks everything downstream. A user who skips logging their weight for a few days would otherwise corrupt streaks, percentages and rankings — punishing them for a lapse in a way that accelerates disengagement.

Notifications are a double-edged instrument. Prompts are what bring lapsed users back, and they are also the fastest route to an uninstall if they arrive too often or at the wrong moment.

Time is local, not server-side. Daily logging windows, weekly leaderboard periods and reminder timing all depend on the user's own day boundary.

Social tables grow forever. Messages, ratings, comments and likes accumulate continuously and are the hottest read paths in the product.

Our Approach

Make peers the mechanism, not the feature. Rather than scoring meals algorithmically or asking users to self-assess, meals posted to a group are rated by the other members. Judgement comes from people the user knows, which is what makes it matter. Every rating is attributed and timestamped, and it drives notification, feed updates and the recipient's history.

Build the domain as events. Every meaningful social action raises an explicit domain event — a meal posted, a rating given, a comment added, a member joining or leaving, a message sent or deleted. Notification, real-time broadcast and derived-state updates all subscribe to those events rather than being written inline. Adding a new consequence to an existing action becomes a new subscriber, not a change to the action itself.

Queue everything that fans out. Posting a meal in an active group can notify and update several people at once. All of that dispatch runs as queued work, so the user's action completes instantly regardless of group size or notification provider latency.

Precompute what is expensive and visible. Leaderboards, rankings, goal percentages and consistency badges are generated by scheduled processes once per window rather than recalculated on every screen load — which keeps the most-viewed screens fast and the numbers consistent between users looking at them simultaneously.

Fill gaps honestly. Rather than letting a missed weight entry corrupt streaks and rankings, the platform backfills the gap on a schedule — and records on each entry whether it came from the user or from the automated process. The metrics stay continuous, and the distinction between reported and inferred data is preserved rather than hidden.

Nudge deliberately. Scheduled reminders for meal and weight logging bring lapsed users back, with the timing and cadence controlled centrally so the volume can be tuned rather than accumulating feature by feature.

Prune what has died. Abandoned groups are cleaned up automatically, so the social surface a user sees reflects live activity rather than accumulating abandoned shells.

Index against reality. Composite indexes on the group, message and rating tables were added, measured and refined against actual query behaviour rather than assumed at design time.

Separate server state from client state on mobile. The app manages cached server data through a dedicated data-fetching layer with targeted invalidation, kept distinct from local UI state — the correct division for a feed-driven product where a single action invalidates several views at once.

The Solution

Closed accountability groups. Users join or are invited into small groups, categorised by tags. The group is the visibility boundary — this is deliberately not a public social network, because accountability works between people who know each other.

Real-time group messaging. Group conversation with read receipts and message likes, delivered live over websockets so the social loop closes in seconds.

Meal posting to the group feed. Users post meals with images into the shared feed, building a personal meal history that is visible to their group.

Peer meal rating. Group members rate each posted meal, with every rating attributed and timestamped. This is the accountability mechanism — the knowledge that a meal will be seen and judged by peers is what changes behaviour.

Comments and likes. Threaded commentary on meals with likes on both comments and messages, giving the group multiple lightweight ways to respond.

Weight tracking with goals. Users record current weight against a target, with progress visualised through charts on the client.

Automatic gap-filling. Missed weight entries are filled by a scheduled process so streaks, percentages and rankings remain continuous, with each entry recording whether it was user-reported or system-generated.

Weekly leaderboards. Rankings computed per week window across weekly loss, overall loss percentage and goal completion, so members can see where they stand relative to their group.

Badges and achievements. Recognition awarded for progress and for logging consistency, giving users a reason to maintain the habit through periods where the scale is not moving.

Scheduled reminders. Automated prompts for meal and weight logging, bringing lapsed users back before the habit breaks entirely.

Notifications with per-user history. Push notification delivery with device registration and a retained per-user notification log.

Content and support. FAQs, content pages, feedback capture and contact enquiries, with everything administratively maintainable.

Key Features

Peer meal rating Meals posted to a group are rated by other members rather than scored automatically or self-assessed — attributed, timestamped, and driving notification and feed updates. This is the mechanism that makes the product work.

Real-time group messaging with read receipts Live websocket-delivered conversation with read receipts and message likes, so social feedback arrives in seconds rather than at the next app open.

Event-driven social architecture Nine explicit domain events decouple actions from their consequences, so notification, broadcast and derived-state updates are subscribers rather than inline controller code.

Scheduled leaderboard generation Weekly rankings across weight loss, overall loss percentage and goal completion, computed once per window so the most-viewed screens stay fast and consistent.

Honest automatic gap-filling Missed weight entries are backfilled on a schedule with provenance recorded per entry, keeping derived metrics continuous without disguising which data the user actually reported.

Consistency-based achievements Badges awarded for logging consistency as well as progress, sustaining engagement through the periods when results plateau.

Automated engagement reminders Scheduled meal and weight logging prompts, centrally controlled so notification volume can be tuned rather than accumulating feature by feature.

Automated group lifecycle management Abandoned groups are purged automatically, so the social surface reflects live activity rather than accumulating dead shells.

Queued notification fan-out All notification and broadcast dispatch runs asynchronously, so a user's action completes instantly regardless of group size.

Progress visualisation Custom charting on the mobile client built over low-level scale and shape primitives, giving progress views tailored to the product rather than generic chart output.

Technical Architecture

Mobile client. A cross-platform application separating cached server state — managed through a dedicated data-fetching layer with targeted invalidation — from local client state, navigated through stack, tab, drawer and swipeable top-tab navigators. Real-time updates arrive over a websocket client; push notifications, image capture and cropping, custom charting and native menus are integrated directly.

API layer. A token-authenticated REST API with controllers separated into member-facing and administrative trees over shared base classes.

Event layer. Explicit domain events raised on every meaningful social action, with notification dispatch, real-time broadcast and derived-state updates implemented as subscribers rather than inline logic.

Asynchronous layer. Queued jobs handling notification dispatch and broadcast fan-out, keeping user-facing actions immediate.

Scheduled computation layer. Six scheduled processes maintaining derived state — leaderboard generation, consistency badge awards, weight gap-filling, reminder dispatch and group purging.

Real-time layer. Messaging and live event delivery through a hosted websocket service, avoiding the operational burden of self-managed socket infrastructure.

Data layer. A relational database with deliberate composite indexing on the group, message and rating tables, plus model-level caching on frequently read, rarely changing data.

Administrative platform. A back office with server-side processed data grids covering users, groups, tags, feedback, content and settings.

Supporting services. Cloud object storage for meal imagery, push notification delivery, error and performance monitoring, and automated deployment.

Flow: Mobile app → Token-authenticated API → Domain events → Queued jobs (notification, broadcast) → Websocket service → Group members' devices, with scheduled processes maintaining leaderboards, badges and gap-filled data

Technology Stack

Technical Challenges & Solutions

Security & Reliability

Authentication. Token-based OAuth2 authentication with email verification and password recovery.

Group-scoped visibility. Group membership is the visibility boundary for meals, ratings, comments and messages. The product is built around closed groups rather than a public social graph, so personal content is not broadly exposed by default.

Surface separation. Member-facing API endpoints and administrative functionality live in separate controller trees.

Data provenance. Weight entries record whether they were user-reported or system-generated, so inferred data is distinguishable from reported data throughout the system.

Notification accountability. A per-user notification log records what was sent, supporting both user-facing history and investigation of delivery complaints.

Media handling. Meal imagery is stored in cloud object storage rather than on application servers, keeping instances stateless and content durable.

Production monitoring. Error and performance monitoring in production with log inspection tooling, giving visibility of real-world failures across a diverse mobile device population.

Repeatable deployment. Automated deployment tooling for controlled, repeatable releases.

Scalability & Performance

Precomputed derived state. The most-viewed and most expensive screens — leaderboards and achievements — read precomputed results rather than triggering calculation, so their cost is per-window rather than per-view.

Queued fan-out. Notification and broadcast work scales with worker capacity rather than with user-facing response time.

Deliberate indexing. Composite indexes on the group, message and rating tables were tuned against measured query behaviour, keeping the hottest read paths fast as content accumulates.

Naturally bounded queries. Because the social unit is a small closed group, feed and message queries are inherently scoped rather than needing to filter a global dataset.

Model-level caching. Frequently read, rarely changing data is cached, reducing repeated database work on common paths.

Delegated real-time infrastructure. Websocket delivery through a hosted service scales with message volume without the business operating socket infrastructure.

Client-side cache management. Targeted invalidation on the mobile client means a single change refreshes only the affected views rather than triggering a broad refetch.

Externalised media. Cloud object storage keeps image traffic off application servers and supports content delivery at scale.

Business Outcomes

• Adherence has a social consequence, because posting a meal means being seen and rated by people the user knows.
• The feedback loop closes in seconds, through real-time messaging and live updates rather than delayed notification.
• Progress is visible and comparable, with weekly leaderboards giving members a reason to return at a predictable cadence.
• Effort is recognised even when results plateau, through consistency-based achievements — the periods where most users would otherwise quit.
• A lapse does not break the user's record, because gaps are filled automatically while preserving the distinction between reported and inferred data.
• Lapsed users are brought back deliberately, through centrally controlled scheduled reminders rather than uncoordinated prompts.
• The social surface stays alive, with abandoned groups pruned automatically.
• The most-viewed screens stay fast as content accumulates, through precomputed derived state and measured index tuning.

Why it worked

Health and wellness apps are rarely lost on features. They are lost on adherence — and adherence is an engineering problem disguised as a product problem. It depends on how fast feedback arrives, whether notifications are coordinated or merely numerous, whether the leaderboard someone checks each week is instant and correct, and whether a single missed day quietly punishes the user into giving up.

Our team builds for that. We put the expensive, socially visible calculations on a schedule so they are fast and consistent for everyone looking at them. We push fan-out onto queues so a user's action never waits on a notification provider. We use an event-driven domain layer so adding a new consequence to an existing action does not mean editing the action. And we handle the small honesty questions carefully — like recording whether a data point came from the user or from the system, so continuity never becomes fabrication.

Our teams work across modern PHP and Laravel, event-driven and queue-based architecture, real-time messaging, cross-platform mobile development with proper server-state management, and cloud media and notification infrastructure — with the product judgement to recognise which mechanic is actually carrying the product, and to engineer around that rather than around the feature list.

Final Summary

Weight-management apps do not fail because they record meals badly. They fail because recording a meal into a private database has no consequence, so within a few weeks nobody does it — and a tracking product with no data has nothing left to offer. Solving that requires changing the mechanism, not polishing the interface.

Our team built a platform where accountability comes from other people. Users post meals into a small closed group, and their peers rate and comment on them in real time. Weight is tracked against goals, progress is compared through weekly leaderboards, and consistency earns recognition even when the scale is not moving. When someone goes quiet, the platform notices and prompts them.

The engineering serves that mechanism directly. An event-driven backend raises explicit domain events on every social action, with notification and real-time broadcast running as queued subscribers so a user's action never waits on fan-out. Scheduled processes precompute leaderboards and badges once per window, keeping the most-viewed and most socially sensitive screens both fast and consistent. Missed weight entries are backfilled automatically with provenance recorded, so a lapse does not corrupt a user's record and inferred data stays distinguishable from reported data. Abandoned groups are pruned, indexes were tuned against measured behaviour, and the mobile client manages server state with targeted invalidation so a single rating refreshes exactly the views it should. It is a product where the retention mechanic and the architecture were designed as the same problem.