Protocol began because I was tired of turning workouts into office work

I built Protocol because I was tired of turning my workouts into an office job.

I had a custom routine with real rules behind it. Progress when this happens. Hold the weight when that happens. Regress after repeated failures. Alternate sessions in the right order. Remember what happened last time.

The training itself was simple enough. The management was not.

I tried tracking everything in Excel. Sometimes I forgot to fill it in. Sometimes the spreadsheet was on my laptop while I was standing at the rack, which meant nothing got logged until hours later, if at all. Using Excel on a phone between sets felt like a form of punishment.

Even when I logged everything correctly, I still had to interpret the data and apply the routine’s progression rules by hand. The spreadsheet remembered numbers. It did not decide anything.

Eventually I realised I was spending too much time managing the workout instead of doing it. I wanted to lift heavy things and be done.

So I built Protocol.

A routine should become the session

The starting idea was simple: put the thinking in once while building the routine, then let the app handle the repetitive decisions during training.

What am I doing today? What weight should I use? Did I earn an increase? Should I repeat the load? Have I failed enough times to regress? Which workout comes next?

Those are not difficult questions in isolation. They are tedious when they arrive one set at a time, while someone is tired, distracted, and trying to train.

A spreadsheet is flexible, which is why people start there. It also asks the person doing the workout to be the programme, the logbook, and the decision engine at the same time. The routine exists, but it is not runnable.

That was the product problem.

Protocol turns a plan into the session itself. It carries the current workout, set targets, rest timing, logging, and progression rules forward from what happened before. The athlete still decides how to train. The product removes the repetitive translation work that gets in the way.

The tracker was never the point

There are plenty of fitness apps already. The ones I tried kept falling into one of two camps.

The first camp was simple tracking. Log the set, record the weight, watch the chart. It was better than Excel in some ways, but the programming logic was still mine to remember and apply. The app stored the evidence, then handed the difficult part back to me.

The second camp was a trainer intake funnel. Answer enough questions, enter enough goals, and eventually the product is trying to sell a programme or a coaching relationship I never asked for.

I did not want another coach. I wanted my own routine to become runnable.

That distinction shapes the product. Protocol should work for someone who already knows what they want to do and needs the plan to carry its own rules. It should also make the entry point easier for someone who does not want to build a routine from scratch.

The app includes popular, freely available routines that a person can pick up and run. If they want to set their own rules, they can. If they want to follow an established plan, the system should make that just as executable.

Train hard. Think less.

That became the slogan because it describes the trade-off I wanted.

Training still requires effort. It should. The app is not there to remove discipline or make every session easy. It is there to remove the small administrative decisions that do not deserve to compete with the work itself.

A routine can have sophisticated progression logic and still feel straightforward when it is being executed well. The athlete should not have to reconstruct the programme from memory, calculate the next weight at the rack, or search through a history of half-finished spreadsheet entries to work out what happened last Thursday.

They should be able to open the app and train.

That is a narrow starting point, but it exposes a broader product question I care about: when does stored information become useful enough to change the next action?

The first version of Protocol answers that through training structure and progression. The longer direction is to understand more of the athlete’s state. A hard session after poor sleep, weak nutrition, or accumulated strain may need a different recommendation than the same session on a normal day. That is the subject of the next Protocol build note.

The point is not another fitness dashboard. It is a training system that knows enough about the plan and the person to make the next decision easier.

Protocol is live as an athlete-side demo: https://useprotocol.app

Why I build alongside consulting

I do not build products to decorate a consulting practice. Protocol needs to stand on its own with people who train, whether or not they ever know what I do with founders and product teams.

Building it does keep my consulting work honest.

It forces me to live inside the same questions I bring to client work: what decision is the product helping a person make, what information does it already have, what does it need to remember, and where is the user still being asked to carry work the system should carry for them?

The domain is different. The product logic is not.

A useful product takes responsibility for the decision it has enough evidence to support.

Keep Reading

Related Posts