Three Trade-offs I Had to Make Building a Desktop Posture App

For two years, I worked in consulting and spent most of my working life at a
laptop. I collected the usual back and neck niggles. They were never urgent
enough to stop me working, so I kept pushing through them.

I knew the advice: sit differently, move more, take breaks. The problem was not
knowing what to do. Posture disappeared from my awareness as soon as I
concentrated. I would notice it after a long meeting or at the end of the day,
when the useful moment to adjust had already passed.

I started building Forma to make those workday patterns visible. Building a
health app around a laptop camera forced three decisions: how much to observe,
how much to show and how much the system could honestly claim.

Misconception 1: More data makes a better product

Continuous monitoring gives a posture model more samples, catches short changes
and reduces gaps. It also leaves a webcam open while someone works, takes calls
and moves through their day.

Local processing keeps the pixels off a server. It does not change the
experience of an active camera.

Forma uses bounded check-ins instead. The Electron main process owns check-in
policy and attempt identity. A hidden renderer opens the selected camera, runs
MediaPipe inference and releases every media track when the attempt completes,
fails or is cancelled. The dashboard never receives camera pixels.

An automatic check-in analyses one fresh three-frame set once the camera is
ready. Setup and manual assessments collect six sets over roughly ten seconds.
Ordinary use retains no camera media. Encrypted local Health Data stores the
derived measurements with capture geometry, model identity and analysis
provenance.

A five-minute cadence provides one observation, not five minutes of evidence.
Forma cannot report what happened between check-ins or reinterpret old video
with a newer model. It accepts those gaps in exchange for less camera access.
The product is meant to reveal recurring patterns, not correct every movement.

Misconception 2: More metrics make a more useful interface

A computer-vision pipeline produces landmarks, visibility, confidence, angles,
relative distances, quality reasons, model versions and capture geometry. That
detail helps debug the model and audit a result. It can also turn the product
into an inference log.

The user should not have to interpret the model. They need to know what changed,
in which direction and whether the evidence is sufficient.

Forma keeps the detailed derived evidence in the data model and applies a
smaller presentation hierarchy:

1. an overall posture summary;
2. five prioritised alignment cards that explain the visible contributors; and
3. a session or workweek view only when enough observations exist.

Each card pairs a measurement with its direction, a calm label and an
illustration. Head turn, for example, remains in the detailed evidence without
competing with the five prioritised explanations.

The detailed evidence remains available for explanation and export. The main
interface shows only what helps someone understand the pattern.

Misconception 3: A better pose model gives a better answer

I first treated accuracy as a problem I could brute-force: use a stronger pose
model, collect more landmarks, add more frames and smooth the result. Those
steps can reduce noise. They cannot recover information the camera never saw.

MediaPipe gives Forma image landmarks and learned 3D coordinates,
but its depth is inferred rather than triangulated or metric. A desk often hides
the hips. The camera cannot see the spine or useful anatomical neck anchors. A
larger model can produce a more plausible reconstruction, but the monocular
problem remains underdetermined.

Camera placement changes the evidence. Camera position materially changes
single-view ergonomic estimates.
Move the laptop, change the hinge angle or sit closer to the screen and the same
posture produces different image geometry. A larger face relative to the
shoulders could mean that the head moved forward, the torso moved, or the camera
did.

A pose model sees points. A posture system can do more by treating those points
as parts of a person. The head, shoulders and torso are connected; their
proportions, joint relationships and movement through time constrain which
interpretations are physically coherent. Those anatomical and kinematic
relationships can remove ambiguity that another batch of near-identical frames
cannot.

This is not about hard-coding one ideal body or posture. A personal reference
accounts for individual variation. Human structure helps the system distinguish
a plausible change in the person from a change in the camera or workstation.

Forma's production model stays within the camera-visible upper body. It
estimates head alignment and rotation, shoulder balance, and qualified proxies
for upper-body leaning and rounding. It excludes hip coordinates. Relative
depth is used only as a within-person comparison against a chosen reference
from the same workstation and stable camera geometry.

Forma Core is research scaffolding for that human-system model. It uses a
short sequence rather than scoring frames independently, keeps camera variables
separate from body state, represents relationships between visible body regions
and treats MediaPipe as a replaceable sensor adapter. It is deterministic
research code, not a trained model or part of production scoring.

A future temporal model could learn from richer monocular teachers such as SAM
3D Body. A fitted mesh remains
a hypothesis from the same limited view. Validation needs synchronised side or
oblique references, measured camera placement and held-out participants.
Without an independent reference, the frontal model would grade its own
reconstruction.

The research question is not how much pose data Forma can accumulate. It is how
well a model can combine limited visual evidence with human structure, time,
camera geometry and a personal reference. Better monocular posture estimation
needs that system around the pose sensor, not just a larger network.

What the beta is testing

The beta tests one idea: a health app can become more useful by limiting itself.
Forma collects less camera data than a continuous tracker, shows fewer metrics
than its pipeline produces and makes narrower claims than a fitted 3D body might
suggest. Those limits should leave enough evidence to reveal a recurring habit
without creating an always-on camera or another dashboard to manage.

If you have built a health or computer-vision product, what technically useful
input or output did you choose to limit for the person using it?

I wrote a more personal account of why I started Forma.
Forma's beta is live on macOS and Windows for UK adults.

---

Disclosure: I used AI assistance to help edit and structure this article and create its diagrams. The personal experience, product decisions and technical trade-offs described here are my own.