Fat Fighters: Building a Frictionless, Social Weight-Tracking Platform

Fat Fighters: Building a Frictionless, Social Weight-Tracking Platform

Fat Fighters started as a practical experiment: could a lightweight, technically simple web application create stronger adherence to daily weigh-ins than traditional calorie trackers or fitness apps? The answer, based on early usage, is yes—but only if the system is deliberately constrained. This post documents the architecture, design decisions, and feature set behind Fat Fighters, and why those choices matter.

Problem Statement

Most weight-loss apps fail for the same reasons: excessive data entry, bloated feature sets, and individual optimisation rather than social accountability. Daily weighing is one of the strongest predictors of successful long-term weight management, but it is also one of the easiest habits to abandon. Fat Fighters focuses on exactly one behaviour: stepping on a scale once per day, in the presence of peers doing the same thing.

Everything in the system is built to reinforce that loop.

System Architecture and Stack

Fat Fighters is a conventional web application by design. There is no mobile app, no background syncing, and no hardware integration. Reducing complexity reduces friction for both users and maintainers.

The core stack is:

• Frontend: Server-rendered HTML with lightweight client-side JavaScript for interactions. No SPA framework. Pages load fast, degrade cleanly, and work on any device with a browser.
• Backend: Python with Flask. Flask was chosen for its explicitness and minimal abstraction layers. Request handling, session management, and business logic are all visible and auditable.
• Database: SQLite via SQLAlchemy. The dataset is append-heavy, read-light, and user counts are modest. SQLite is sufficient, reliable, and trivial to back up.
• Authentication: Session-based auth with hashed credentials. No OAuth dependency at this stage, intentionally.
• Hosting: Single VPS with Nginx reverse proxy. No serverless components, no vendor lock-in.

This architecture keeps operational risk low. A single engineer can understand and operate the entire system end-to-end.

Data Model and Integrity

At the heart of Fat Fighters is a deliberately boring schema:

• Users
• Groups
• Daily weigh-in entries
• Target weights and baselines

Key design constraints:

• One entry per user per day. This prevents gaming and removes ambiguity.
• Editable historical entries. Mistakes happen. Allowing corrections avoids rage-quits.
• Backfilling allowed. Missed days can be recovered without breaking long-term trends.

The system never deletes data silently. All changes are explicit and reversible at the application layer.

Feature Set (and Why Each Exists)

Fat Fighters has fewer features than most fitness apps, and that is intentional.

Daily weigh-in logging enforces a single daily action. Calendar views expose gaps immediately, making avoidance visible rather than abstract. Streak tracking provides short-term reinforcement, while baseline deltas anchor progress to a fixed starting point rather than daily noise.

Rolling seven-day change metrics smooth out variance without hiding trends. Distance-to-target and ETA calculations translate abstract numbers into something actionable. Group leaderboards introduce mild competitive pressure, but rankings are based on consistency and delta, not absolute weight.

Notably absent are calorie tracking, workout logging, body measurements, and integrations. Each of those increases cognitive load and decreases compliance with the core habit.

Social Layer by Design

Fat Fighters is not anonymous. Users join small, closed groups. Everyone sees everyone else’s consistency. This is not accidental.

From a systems perspective, the social layer is the primary enforcement mechanism. The application does not nag. People do. The UI simply makes lapses visible in a neutral, non-judgemental way.

This is closer to a distributed accountability system than a traditional fitness app.

Security and Privacy Considerations

Weight data is sensitive, but not regulated medical data. Even so, basic hygiene is enforced:

• Passwords are salted and hashed.
• Sessions are server-side.
• No third-party trackers or analytics scripts.
• No data resale, exports only on user request.

By avoiding mobile SDKs and ad platforms, the attack surface is materially smaller.

What’s Next

Future work is intentionally conservative. Potential additions include CSV export, optional OAuth login, and lightweight notifications—but only if they reinforce the daily weigh-in loop rather than dilute it.

Fat Fighters is an example of applying engineering restraint to a behavioural problem. The technology is simple. The system dynamics are not. That is where the real work lives.