Fitness App - Liftalot

Decide what the app refuses to do before writing anything, because that is the whole product.

1. Done

   Scaffold Next.js and TypeScript

   App Router, strict TypeScript, Tailwind. Mobile-first from the first commit, since every real use of this app happens on a phone.

2. Done

   Write down what it will not have

   No estimated 1RMs, no programme builder, no wall of statistics. Deciding this first is what kept the logging screen fast.

3. Done

   Model a workout

   A workout holds exercises, an exercise holds sets, a set holds reps and weight. Shallow enough that logging never needs more than two taps.

4. Done

   Accounts and persistence

   Sign-in and per-user storage, so a training history survives a new phone. The one piece of infrastructure the app genuinely needs.

The core loop. If this is slow, nothing else in the app matters, because the log stops being accurate.

1. Done

   The logging screen

   Add an exercise, add sets, enter reps and weight. Built to be usable one-handed, between sets, without looking up.

2. Done

   Prefill from last time

   Most sets repeat what you did last session. Starting from those numbers turns logging into confirming rather than typing.

3. Done

   Exercise library

   A searchable list of movements with your own additions, so the same lift is named the same way every week and history actually joins up.

The part that makes it Liftalot rather than another logger — rewarding consistency without punishing a rest day.

1. Done

   Activity streak

   A streak that counts showing up, not intensity, so an easy session still counts and one missed day is not a reset.

2. Done

   Count walking and everyday movement

   A long walk is not a wasted day. Counting it towards the streak is what stops the app quietly telling you that only lifting is real training.

3. Done

   Progress over time

   Per-lift charts showing the trend, not a dashboard of derived metrics. Enough to see you are moving without inviting you to over-analyse.

Cheap, quick, and the difference between a repo and something you actually open at the gym.

1. Done

   Welcome and onboarding

   A short first-run flow that explains the streak rules up front, since the rest-day behaviour is the bit people do not expect.

2. Done

   Tune it for a phone at the gym

   Large tap targets, no hover-dependent controls, and a layout that survives being used with one thumb and chalky hands.

3. Done

   Deploy to Vercel

   Preview deployments per branch and a live demo anyone can open without signing up first.

Numbers record what you lifted. They do not record that your shoulder felt off, or that the bar moved better at a slower tempo.

1. Planned

   Add notes to each exercise

   A free-text note per exercise in a session — form cues, niggles, how it felt. The context that makes last week's numbers mean something.

2. Planned

   Surface the last note while logging

   A note you cannot see next time is a note you did not need to write. Showing the previous one inline is what makes the feature pay off.

3. Planned

   Keep it optional and out of the way

   Notes must not add a step to the common path. Collapsed by default, one tap to open, never a field standing between you and the next set.

Gym basements do not have wifi. An app that loses a session to a dead connection stops being trusted, and a tracker you cannot trust is worse than a notebook.

1. Planned

   Write to local storage first

   Every set is saved on the device the moment it is entered, with the server as a sync target rather than the source of truth. Nothing is ever lost waiting on a request.

2. Planned

   Installable offline shell

   A service worker caching the app shell and the exercise library, so it opens and logs with no connection at all — not just when a request happens to fail.

3. Planned

   Sync when the connection returns

   A queue that drains on reconnect. Sets are append-only and single-user, so ordering by timestamp resolves nearly everything without real conflict handling.