paaart.dev← Back to Projects

Current Version

Personal Training System

A personal training planner focused on consistency, training structure, mobility, recovery, diet, skincare, and reducing friction.

Active Developmentv0.7Health & Performance

Why This Exists

I was tracking workouts, routines, diet, skincare, and mobility through static documents and PDF-style planning. That worked while the system was small, but it became annoying to update and hard to use consistently once the plan started changing week to week.

Current Capabilities

  • Weekly workout checkboxes
  • Collapsible workout sections
  • Workout templates
  • Weekly rhythm planning
  • Set logging
  • Mobility and recovery planning

Current Focus

  • Consistency
  • Training structure
  • Mobility
  • Recovery
  • Reducing friction

Evolution Path

Personal Training System

This is the first rough Project Evolution entry for my personal training planner app. The project is not really about building a polished fitness product. It is about turning a system I was already trying to follow into something easier to maintain, easier to open, and harder to abandon.

The app grew out of a simple frustration: static planning files were useful for thinking, but not great for living with.

v0.1 — Static Planning Era

Problem / Trigger

I was tracking workouts, routines, diet, skincare, and mobility through static documents and PDF-style plans. They looked clean enough, but every update felt heavier than it should have.

If a workout changed, I had to edit the document. If a routine shifted, the plan became stale. If I missed something, the system did not help me recover. It just sat there as a nice-looking file that slowly stopped matching reality.

Thought Process

At first, the document approach made sense because I wanted structure. I wanted to see the whole plan clearly. I wanted something that felt intentional, not random notes scattered around.

But the more I used it, the more obvious the tradeoff became: static planning is good for designing a system, but bad for operating one day after day.

What Changed

  • Noticed where the static plan was creating friction.
  • Identified workouts, diet, skincare, and mobility as separate but connected parts of the same system.
  • Started thinking about the plan as something that needed to be operated, not just written.

Lesson Learned

A plan that is hard to update eventually becomes decoration.

Next Question

What would this look like if it behaved more like a tool I use every day, instead of a document I occasionally revise?

v0.2 — First Web Planner

Problem / Trigger

The first real trigger was wanting a version of the plan that could live in the browser and feel more active. I did not need a full app yet. I just needed the planning system to stop feeling locked inside a static file.

Thought Process

The goal was not to build a huge fitness platform. The goal was to lower the cost of opening the plan, changing it, and following it.

React, Vite, TypeScript, and Tailwind made sense because they let me move quickly while still keeping the structure clean enough to grow.

What Changed

  • Moved the planner into a mobile-first web app.
  • Created dedicated areas for Diet, Skincare, and Workouts.
  • Started treating the planner as an interface instead of a formatted document.

Lesson Learned

The first useful version of a personal tool does not need to be comprehensive. It needs to be reachable.

Next Question

What parts of the plan need interaction, and what parts only need to be readable?

v0.3 — Workout Structure

Problem / Trigger

The workout section needed more structure than a simple list. Training has too many moving parts: exercises, days, templates, sets, and the difference between what I planned and what I actually did.

Static text was not enough once the workout plan needed to support repetition and variation.

Thought Process

I started thinking of workouts less like notes and more like reusable patterns. Some parts of the week repeat. Some parts change. Some exercises belong together. Some details should stay out of the way until I need them.

That pushed the app toward collapsible sections and workout templates.

What Changed

  • Added weekly workout checkboxes.
  • Added collapsible workout sections.
  • Added workout templates.
  • Made workout types easier to scan on mobile.

Lesson Learned

Structure is most useful when it reduces decisions, not when it adds more surfaces to maintain.

Next Question

How much of the week should be planned in advance, and how much should stay flexible?

v0.4 — Weekly Rhythm

Problem / Trigger

Once workouts had structure, the next issue was rhythm. A workout plan is not just a list of sessions. It has a shape across the week.

Some days need intensity. Some days need recovery. Some days are better for mobility or lighter work. Without a weekly rhythm, the app could show workouts but not really help guide the week.

Thought Process

I wanted the app to make the week easier to understand at a glance. Not in a rigid productivity-system way, but in a practical training way: what kind of day is this, what needs to happen, and what should I avoid overloading?

What Changed

  • Added clearer weekly training flow.
  • Connected checkboxes to weekly consistency.
  • Made workout frequency more visible.
  • Started treating training days and recovery days as connected.

Lesson Learned

Consistency is easier when the system shows the shape of the week, not just the tasks inside it.

Next Question

How can the app help me recover from an imperfect week instead of making the plan feel broken?

v0.5 — Mobility & Recovery

Problem / Trigger

Training was not the only thing that mattered. Mobility and recovery were part of the reason for building the system in the first place, but they could easily become secondary if the app only emphasized workouts.

I needed the planner to support the less dramatic parts of training too.

Thought Process

Mobility and recovery are easy to under-track because they do not feel as concrete as sets or workouts. But they affect whether the whole system is sustainable.

The app needed to make those habits visible without making them feel like a second workout plan.

What Changed

  • Made recovery part of the weekly structure.
  • Gave mobility more explicit space.
  • Shifted the app from workout checklist toward training support system.

Lesson Learned

The quiet parts of a system need space too, otherwise the loudest parts take over.

Next Question

How should recovery be tracked without making it feel like another obligation?

v0.6 — Set Logging

Problem / Trigger

Once the plan became easier to follow, the next missing piece was logging what actually happened. Checkboxes could show that I trained, but they could not capture enough detail about the work itself.

For workouts, sets matter. Without set logging, the app was still partly dependent on memory or separate notes.

Thought Process

I did not want logging to become heavy. The whole point of the app was to reduce friction. So set logging had to be useful enough to record training, but light enough to use in the middle of a workout.

The tension was between detail and speed.

What Changed

  • Added set logging to make workout tracking more concrete.
  • Let planned workouts become completed workouts.
  • Moved the app closer to being useful during training, not just before or after.

Lesson Learned

Tracking only works if the effort of recording does not compete with the effort of doing.

Next Question

What is the minimum useful training log that still helps me progress?

v0.7 — Personal Operating System

Problem / Trigger

By this point, the app was no longer just a workout planner. It included diet, skincare, workouts, mobility, recovery, weekly rhythm, and logging. The deeper problem was not any one feature. It was the need for one place where the recurring parts of my personal system could live.

Thought Process

The phrase "personal operating system" can get too grand, but the idea fits here in a grounded way. This is a small system for reducing repeated decisions and keeping important routines visible.

It does not need to be universal. It just needs to fit the way I train and take care of myself.

What Changed

  • Diet, skincare, and workouts now live together.
  • The app is mobile-first because the system needs to be usable in real life.
  • Training structure and recovery are treated as connected.
  • The focus shifted from planning perfectly to staying consistent.

Lesson Learned

A personal app gets better when it is honest about the life around it. The goal is not to design the perfect system. The goal is to make the real system easier to return to.

Next Question

What should the app remember for me, and what should it let me decide fresh each week?

Lessons Learned

  • A plan that is hard to update eventually becomes decoration.
  • Structure is useful when it reduces decisions.
  • Recovery and mobility need to be treated as part of the training system, not extras.

Current Questions

  • What should the app remember for me?
  • What should stay flexible each week?
  • How can set logging stay useful without becoming heavy?

Future Direction

Keep turning the planner into a practical personal operating system for training, recovery, and repeatable routines without making it feel overbuilt.