Personal Trainer Workspace

Working as an independent contractor, I built a personalized SaaS workspace platform from 0 for an independent fitness trainer — single-handedly completing the full product cycle from requirement interviews, UX/UI design, system architecture, and full-stack development (AI-assisted) to testing and delivery.

The client had been using Excel plus Line to manage students, schedules, lesson records, and monthly payments — information scattered and hard to track. I broke this down into four core modules: calendar, student management, sales analytics, and automated reminders, and used “phased delivery” to control scope and budget. In practice it cut the trainer’s administrative work from 3–4 hours a week to about 1 hour a month, earned positive client feedback, and we’re currently in talks about a second phase of expansion.

Project Background

The client is an independent fitness trainer who had been using Excel plus Line to manage the student roster, schedules, and lesson records, as well as to track payments and tabulate monthly income. Information was scattered everywhere and hard to track, and every month a fair amount of time went into administrative work. He wanted a personalized SaaS platform that integrated a calendar, student management, sales analytics, and automated reminders.

What made this case special: I played the role of a complete product team by myself — from facing the client to clarify requirements, through design, development, and delivery, all done independently from start to finish.

My Role and Dual Perspective

I was both the designer and the engineer for this product, completing the full-stack development with AI assistance (Claude Code). On design, I worked out the trainer’s real work rhythm from the interviews and worked backward to what the interface should look like; on the project, I faced the client independently and owned the decisions around scope control and phased delivery. Below I explain across two dimensions — “design decisions” and “project management” — picking the most representative example of each.

Design Decisions: Working Back to the Interface from the Trainer’s Real Work Rhythm

During the interviews I worked out the trainer’s four work cycles — “recruit → schedule → teach → settle” — and found his highest-frequency need was “checking in and recording lesson content on a phone during the lesson itself.” So I made the calendar the system’s home page and built a shared check-in-and-lesson-record interface directly into the daily-schedule view, eliminating the steps of repeatedly jumping between different modules.

2. A “lesson group” mechanism to replace error-prone multi-sheet billing reconciliation

The trainer charges at two points in time: prepaid before the lesson, or billed monthly after. Previously he had to cross-check across multiple Excel sheets — tedious and easy to miss things. I designed a “lesson group” mechanism that organizes lessons by their charging point and automatically separates the portions that do and don’t need to be reconciled each month; once the trainer reconciles the lessons, the system automatically settles that month’s billing, greatly simplifying the original multi-sheet reconciliation process.

3. Adding “action review” so the new system keeps the convenience of the old way of working

Moving from Excel to a system lightened a great deal of the cognitive load of side-by-side data, but it also lost Excel’s convenience of “comparing lesson history left and right.” For this I introduced an “action review” window that separately extracts the student action history the trainer most often needs to reference, available for lookup — so the trainer enjoys the new system’s tidiness while keeping the genuinely useful parts of the old habit.

Project Management: Using Phased Delivery to Balance Client Budget Against System Completeness

As an independent contractor, I’m responsible for both “client budget” and “system completeness” at the same time. I split the full requirements into two separate contracts — the first phase focused on the trainer’s internal management, and only the second phase builds the student self-service interface — and clearly marked alternatives in the proposal, letting the client validate the system’s value at a lower cost first while keeping the project scope within bounds that don’t lose focus.

This decision was the most important lesson in my contracting experience: a client doesn’t necessarily need a complete, all-at-once system. Delivering the high-value core first and using the results to persuade the client to continue actually builds long-term trust better. The actual results bore this out — after the first phase was delivered, the client proactively raised a second phase of expansion and began planning the subsequent business model and trainer-to-trainer promotion with me.

Outcomes

Completed the full product cycle independently: requirement interviews → scope definition → UX/UI design → system architecture → full-stack development → testing → delivery
Designed and implemented four core modules — calendar, student management, sales analytics, and reminder notifications — cutting the trainer’s administrative work from 3–4 hours a week to about 1 hour a month in practice
Built a system-administrator backend for later managing multiple trainer accounts and tracking system resource usage, laying the groundwork for a future B2B2C model
Completed the first-phase delivery, passed a 1-month trial, and opened a 1-year warranty; the client is now in talks about a second phase of expansion

Reflection

This case validated the work experience I’d accumulated — that one person can run an entire product cycle — and made me more familiar with the new generation’s AI-assisted development model. The biggest takeaway was experiencing the value of “phased delivery” when resources are limited: rather than chasing completeness in one go, it’s better to deliver the core that creates value immediately, let the client validate it at low risk, and then decide how to move forward.