Vibe coding
Introducing Vires: a training platform for PTs and their clients
Why I built Vires, what it does for personal trainers and clients, and the decisions behind it, from the weekly plan builder to private health data.

Vires is a web platform where a personal trainer (PT) builds a training plan for each client, and the client logs their own results after every session. I built it to replace a single HTML page that tracked my own training. This post covers why it exists, what it does and the decisions that shaped it.
Short version: the PT designs the plan, the client records the work, and both see the same data. It is built for phones in a gym with weak signal, and for laptops where plans get designed.
Where it started
I had a tracking page for my own workouts: tabs by day, a card per exercise with a red muscle figure, and rows to enter kilograms and reps. It was fast and I liked using it. It also had three limits:
- It served one person.
- The plan was hard-coded in the page.
- There was no place to see body metrics or progress over time.
A PT who wanted the same thing for their clients had nowhere to build a plan per person. A client had nowhere to look back at how they were doing. Vires is that missing platform.

What it does
There are three roles, and each sees only what it needs.
The PT
- Signs in with Google and keeps a list of clients, searchable by name or email.
- Records body metrics (weight, muscle mass, fat mass, body fat percentage, InBody score) and uploads InBody images.
- Builds a weekly plan by dragging exercises from a library into days, then adjusts sets, reps, notes, supersets and dropsets.
- Activates the plan, copies the tracking link and sends it over Zalo or text.
- Follows results week by week, with the previous session shown next to each exercise.
The client
- Opens the link from the PT and signs in with Google using the email the PT registered.
- Sees today's tab first, with a card per exercise: the muscle figure, the PT's notes, target sets and reps, and last time's result.
- Logs kilograms and reps per set and ticks each set done.
- Opens a profile page to see body metrics, charts and InBody images, and can add their own.
The admin (me)
- Approves new PTs, manages the shared exercise library and reviews exercises that PTs create themselves.

Three decisions I'd defend
1. The plan builder has to work on a phone
Dragging exercises into a weekly schedule is natural on a laptop. On a phone it is not. So the builder has two ways to do the same thing: drag and drop with a mouse or touch, and an "Add to day" button with up and down buttons everywhere else. Both work with a keyboard. A feature that only works with a mouse is not finished.
2. Logging a set must never wait for the network
Gyms are often basements and corners with poor signal. Every entry saves locally first and syncs when the connection returns, and a small status line says "Saved" or "Waiting to sync". The client never has to wonder whether the last set made it.
3. The link is not a key
The tracking link contains a random plan id, which is hard to guess. But the link alone grants nothing. The client must sign in with the email the PT registered, and the security rules compare that identity with the plan. If a link is forwarded to the wrong person, they see "This link is for another account" and nothing else.
Handling health data
Body metrics, InBody images and injury notes are personal data, and the health part is sensitive. Four rules apply from the first version:
- A PT sees only their own clients. A client sees only their own data. The rules enforce this, not the interface.
- The phone number is stored in a server-only document and is always shown masked.
- Images sit in a private bucket and are reached only through short-lived links the server issues after checking permissions.
- Clients accept a consent screen on first sign-in and can export their data or ask for deletion.
How it's built
The stack is a pnpm and Turborepo monorepo with two Next.js apps (the PT and client portal, and the admin portal), TypeScript in strict mode, Tailwind CSS v4 and Flowbite React behind a shared UI package. Firebase provides sign-in and Cloud Firestore, files go to a private Backblaze B2 bucket, and Vercel hosts the apps. Zod schemas are shared between browser and server, and dnd-kit powers the drag and drop.
I vibe coded it with Claude, working from a written spec and short sprints, each ending in a working build I reviewed. The method is the same one I described in Vibe coding my portfolio end to end. The full case study is in Work.
What's next
The roadmap after the 1 December launch, in the order I plan to take it:
- Extended PT profiles (experience, number of clients).
- Reading InBody results automatically from images.
- Charging when a PT passes 10 clients.
- Training reminders and alerts for missed sessions.
- Volume charts per exercise.
FAQ
What is Vires?
A web platform where personal trainers build weekly training plans for each client, and clients log kilograms and reps for every set on their phone.
Who is it for?
PTs who manage a small group of clients and want one place for plans, metrics and results, and for their clients who want to track and review their own training.
Does it work offline?
Entries are stored on the device and synced when the connection returns, so logging a set works with weak signal in the gym.
Is my health data safe?
Access is limited by role and enforced by security rules, files are private, phone numbers are masked, and clients can export or delete their data.
Is it free?
In the early phase, yes. Each PT can have up to 10 clients. Charging for more is a planned feature.