SaraFit

01What the business needed

An online trainer with a growing client base was running her business out of a phone. Inquiries arrived as Instagram DMs. Meal plans were PDFs sent by hand, each one adjusted for the client's calorie needs after a manual calculation. Workout videos lived in scattered links. Progress tracking meant asking each client, individually, how the week had gone.

That model works for ten clients. It breaks at fifty. Every new client added a fixed amount of admin work that only the trainer could do, so her income was capped by her calendar rather than by demand. She also had no storefront — no way for a stranger who found her on Instagram to understand what she offers, see proof it works, and ask to join.

She needed two things at once: a front door that sells, and a back office that removes her from the repetitive parts of delivery.

02The public site — a front door that qualifies

The marketing site has one job: turn a visitor into a qualified inquiry. The home page leads with the trainer's specialisation — coaching for women, six-plus years of experience — because a narrow promise converts better than a broad one, then walks through what she offers, what results to expect, and social proof from named clients.

Each program has its own page and its own inquiry form, so the trainer knows which program a lead is asking about before she replies. The form is deliberately short — name, email, phone, an optional message — with a plain-language consent line rather than a legal wall.

Articles are content-managed from the admin and surface on the site and in the sitemap on their own. Localised metadata, clean slugs, and a sitemap that stays in sync as programs and articles are added — no developer needed to publish anything.

03The client dashboard — where the coaching happens

Once a client registers, the product shifts from marketing to delivery. The dashboard is the place a member opens several times a week: the assigned meal plan day by day with calories and macros, the training plan week by week, a video library of exercise demonstrations weighted toward correct technique rather than volume, a calorie calculator, and a progress view — how they are tracking over time, not only what they are supposed to do today.

Designed mobile-first, because realistically a client opens her meal plan on a phone in a kitchen and checks a workout video on a phone in a gym. Desktop is the secondary case.

04The automated meal-plan match

This is where the platform stops being a website and starts being a product. The client fills in the calorie calculator with her own data; the system computes her target intake and immediately proposes the meal plan from the trainer's library that matches those numbers. She accepts it — it is assigned to her dashboard on the spot — or requests a different one, which routes to the trainer instead of dead-ending.

The design choice that matters is the second option. A fully automatic assignment would be faster, but it would strip the trainer out of a decision that sometimes needs her judgement — allergies, preferences, medical context. So the automation handles the common case and hands the exception back to a human. Her time goes to the clients who need it instead of to the arithmetic that doesn't.

05The admin panel — the business in one place

The trainer runs everything herself, so the admin had to be complete enough that she never needs me. Meal plans — created, edited and retired, with the calorie ranges she sets being what the matching engine draws from. Training programs, built and published to the public site. Every inquiry from every program form in one queue with its context attached. Client accounts and what each has been assigned. Per-client statistics, so she can spot who is stalling before they churn. Blog and video content.

Everything a visitor or a client sees is data she controls. Nothing on the platform requires a deployment to change.

06Design

The interface was designed before any of it was written. The visual language is deliberately restrained: a dark, muted green as the anchor colour, generous whitespace, confident typography, and large photography of the trainer herself. Fitness sites default to loud gradients and shouting; this one is quiet, which reads as competence rather than hype — and competence is what someone is buying when they hand their nutrition to a stranger.

The public site and the dashboard share one system — the same palette, type scale and components — so the moment a client registers the product feels continuous rather than like a second app bolted on behind a login.

07How it is built

Next.js, with Supabase providing Postgres, authentication and file storage, deployed on Vercel under a custom domain so a release is a push rather than an event.

The public pages are server-rendered for speed and search; the authenticated dashboard is built for interactivity. One codebase, two rendering strategies matched to two different jobs. Access control is row-level at the database: a client can only ever read her own plans and progress, enforced where a bug in a component cannot leak another member's data. Programs, meal plans, workouts and articles are rows the admin owns — which is why the sitemap, program pages and blog stay current on their own, and why the trainer's day-to-day never routes through me.

08Outcome

The business has a storefront that works while the trainer sleeps, a structured intake that replaces DM triage, and a delivery platform that scales past what one person can manually service. The repetitive work — calculating calories, matching a plan to them, sending it, chasing progress — is the software's job now. The trainer's time goes to coaching.

Live and in use with real clients, and looked after under the same ongoing care offered to every client here.