Augment Fit Platform

What is the Augment Fit Platform for?

The platform is aimed at a plain gap: trainers and the people they train need one place to manage training sessions, track performance and plan what comes next. That is a coordination problem before it is a software problem. Training is a relationship with data inside it. A trainer decides what to prescribe next from what happened last, and a trainee keeps going by seeing whether the work is moving anything at all. Both sides are reasoning about the same history, and both need it to be the same history.

A platform of this kind exists to make that history one record rather than two accounts of it. That is what Augment Fit is designed to be: a fitness management platform connecting trainers and users, with an admin panel and a dashboard that track sessions and performance.

How do React and Supabase fit a platform like this?

The stack is React for the front end, Supabase for data and Vercel for hosting, and that pairing suits this class of product.

A training platform is a structured-records domain. Sessions, tracked performance and plans are related to each other, queried repeatedly, and meaningful mainly in relation to each other, which is the workload relational databases exist for. Supabase's data layer is Postgres, so that half of the fit needs no argument.

When one trainer's data and another user's data live in the same system, authorisation is a design problem that has to be solved deliberately somewhere. In a Supabase project the usual place is row-level security policies written beside the tables they protect.

Why does a fitness product need both an admin panel and a user dashboard?

The platform has two surfaces: an admin panel, and a dashboard through which users connect with trainers and see their sessions and performance.

The two surfaces answer to different audiences. An end user's dashboard is scoped to one person's own data and is opened to answer a small number of questions about it. An operational surface exists to work across accounts, which is a different job carrying a different permission level.

Keeping them apart also keeps the permission model legible. Cross-account visibility is precisely the capability that ordinary user access is designed to withhold, so putting it behind its own surface makes the elevation explicit rather than something a general-purpose screen quietly acquires. Merging the two usually costs both audiences: clutter for one, missing capability for the other.

How do performance tracking and BMI classification shape the data work?

Two of the features, performance tracking and BMI classification, pull on stored data in different ways.

Performance tracking is inherently comparative. A weight, a repetition count or a completed session carries little meaning alone and a great deal beside the same measurement recorded earlier, which is why products in this category generally keep observations as dated records rather than as one current value that is overwritten each time. The trend is the product, and a trend needs its own past.

BMI classification is a derived label rather than a fact in its own right. It is computed from height and weight against published bands, and the durable habit is to keep the inputs and derive the category when it is read. That keeps unit handling in one place and leaves earlier readings correct if the way those bands are presented ever changes.

What does workout plan building ask of the interface?

Workout plan building is one of the platform's features, and a builder is an editing surface, not a reading surface. Most of a dashboard renders data and then waits; a builder changes shape while someone works inside it, which makes interface state the dominant concern. That is the case React's component model is well suited to, because a small change in one part of the form redraws that part rather than the view around it.

The other general demand is keeping a template distinct from a record of what happened. A plan describes an intention; tracked performance describes an event. Products that let edits to the first reach the second make their own history unreliable, and that is a data-modelling decision rather than an interface one.

What does TypeScript add to a data-heavy front end like this?

TypeScript is part of the stack, and what types are worth here is specific to the domain. A fitness dashboard is mostly numbers and dates: a measurement, a session and a plan entry can all be objects of the same primitive shapes, and confusing them does not produce a crash. It produces a plausible wrong figure on a screen someone is using to decide what to train next. Silent wrongness is the expensive failure mode in this kind of product, and naming the shapes explicitly is the cheapest available guard against it.

Types also make a front end safe to keep changing. When the interface holds the data contracts for many screens, a compiler that checks those contracts converts a class of runtime surprise into an error the developer sees first, before it reaches a trainer or a trainee.

Why host a front end like this on Vercel?

The panel was deployed on Vercel, and the fit is straightforward. A React front end compiles to static assets the browser must fetch before it can render anything, and those assets have no reason to travel from a single origin to every user. Serving them from locations near the user shortens the part of the load that is pure distance, so the shell of the application behaves similarly wherever it is opened, while requests for data go to the data layer.

That division also keeps front-end releases cheap. A built front end is a versioned artefact rather than a machine held in a particular state, so shipping a change and reverting one are the same kind of operation. For an interface that gets iterated on, that matters.

Can you see Augment Fit today?

No. The Vercel address the panel was deployed to does not currently serve a working page and there is no store listing, so Augment Fit has no working public link. Sameem worked on the panel in React and TypeScript, with Supabase for data and Vercel for hosting; the sections above explain why that stack suits an admin panel of this kind.

Why this stack

• React: it is the front end, and a dashboard is the case a component model handles best. The screen is a set of repeating shapes, rows, cards and panels that render many times over different data, which components express directly instead of through hand-written DOM updates. Workout plan building adds the other half of the argument, since a builder is an editing surface where a small state change should redraw one part of the form rather than reload the view around it.
• Supabase: it handles data, and its data layer is Postgres, which matches the domain. Training sessions, tracked performance and plans are related records queried in relation to each other, which is relational work rather than document work, and it benefits from a database that can enforce shape and answer aggregate questions directly. A managed service also keeps the operational cost of running that database off a project whose value sits in its product surfaces.
• TypeScript: it is part of the stack, and the payoff is domain-specific. In a fitness product, measurements, sessions and plan entries are all combinations of numbers and dates, so mixing them up yields a believable wrong number rather than a visible failure, which is the worst kind of bug in an interface people use to make training decisions. Types name those shapes so the compiler can keep them apart, and they make a growing front end safer to keep changing.
• Vercel: the panel was deployed there. A React front end ships as static assets that have to arrive before anything renders, so serving them from locations near the user removes the part of the load that is pure distance, while stateful requests continue to the data layer. The deployment unit becomes a versioned build to promote or roll back rather than a server to be kept in a particular state.