Building a digital coach, and changing the version that could not scale

The problem

People who lift weights consistently get two things wrong. They get the execution wrong, meaning technique, posture and tempo, and they get the intensity estimate wrong, training either too far from failure to grow or too close to it to recover. Both are invisible to the person doing them, which is why a coach is valuable.

The evidence behind the pitch, sourced rather than asserted:

• 53% have been injured at least once through incorrect execution of an exercise.
• 32% of those injuries left permanent pain.
• 47% misjudge the intensity they are actually placing on the muscle.

Every number in that list carries a source rather than an assumption, a habit I kept for the competitive audit work I do now. That framing mattered more than it might appear. It moved the product away from being a fitness tracker, a saturated category competing on step counts, and towards being a substitute for a coach, which is something people already pay significant money for.

The competitor matrix that shaped the roadmap

I benchmarked OptimaLifts against four established players in the market on five capabilities, each chosen because it maps to a user need rather than to a spec sheet:

1. Set and repetition tracking
2. Movement and technique tracking
3. Speed and intensity tracking
4. R.I.R. calculation, meaning reps in reserve, or how many repetitions remain before muscular failure
5. Affordable and discreet implementation

The matrix showed the field splitting clearly. The established players each covered one or two of the first three capabilities, very few combined technique with intensity, not one of them offered R.I.R. calculation at all, and the products that came closest were expensive and conspicuous. Rows 4 and 5 were where the opportunity sat, so I made them the two things the product was not allowed to compromise on.

Changing direction: from sensors to the camera

The first version was a wearable, with sensors recording movement, rep speed and volume and feeding a digital coach. It took us to a national final at the JA Greece startup competition with a working Arduino and IoT prototype, a full business plan and a validated model. It also came with a unit economics problem that could not be argued away.

So we changed direction. The concept stayed the same, counting the reps, judging the form and estimating how close to failure the lifter is, while the sensing moved to the smartphone camera and a pose-detection model. That meant hiring for a skill nobody on the team had.

Hiring for a skill I did not have

I ran the process for our Computer Vision Engineer end to end. I wrote the job description, sourced and tracked applicants, ran first interviews from a written structure, kept written notes on each candidate so the decision was comparable rather than remembered, and handled the replies, including the rejections.

It is the closest thing to product work that is not product work. You are defining a role from an ambiguous need, screening against criteria you had to create, and making an expensive and hard-to-reverse decision on incomplete information. It also changed how I write acceptance criteria. If I could not state what good looked like for a candidate, I had no business asking someone to build to it either.

The product: coaching that arrives during the rep, not after it

This is the part that makes OptimaLifts a coach rather than a log. The correction does not come at the end of the set, or in a video review that evening. It appears while the repetition is still happening, in the fraction of a second where the lifter can still change what their body is doing. That is the difference between being told you got it wrong and being stopped from getting it wrong.

Everything else in the product follows from that one constraint. The whole loop, from the camera frame to the words on screen, has to complete inside a single rep, which ruled out anything that needed to be uploaded, queued or reviewed later.

I mapped the use cases for the full product, covering profile and body data, auto-generated plans, workout navigation, guided execution with rest timers, live performance, a social feed, statistics and leaderboards, an "Optimal Academy" knowledge section with an AI chat, and settings. I then prioritised them into release groups, with the live coaching loop first, because a product that cannot do that convincingly does not need any of the rest.

The first demo covered five exercises and detected all their main execution errors, with rep counting, stage detection and the live correction working end to end.

One of the user stories behind that loop, written the way I write them: the statement, the acceptance criteria as Given, When and Then, the rules any implementation has to respect, and an explicit list of what the story does not cover.

User story

Movement tempo feedback

As a trainee working out alone, I want to know in real time when I am performing a repetition too quickly or too slowly, so that I can adjust my movement to the intended exercise tempo.

Acceptance criteria

AC1 Detect movement that is too fast

• Given the trainee is performing a supported exercise in front of the camera,
• When the trainee performs a repetition faster than the intended tempo,
• Then the app displays an actionable cue while the repetition is still in progress.

AC2 Detect movement that is too slow

• Given the trainee is performing a supported exercise,
• When the trainee performs a repetition slower than the intended tempo,
• Then the app displays an actionable cue while the repetition is still in progress.

AC3 Keep feedback actionable

• Given a tempo deviation is detected,
• When the corrective cue is displayed,
• Then the cue tells the trainee how to adjust their pace rather than presenting a technical speed measurement.

AC4 Remove feedback when the tempo is corrected

• Given a tempo corrective cue is being displayed,
• When the trainee returns to the intended pace,
• Then the cue clears automatically without requiring interaction with the device.

AC5 Avoid unreliable tempo feedback

• Given the system cannot reliably assess the trainee's movement speed,
• When there is insufficient visual information to determine the tempo,
• Then the app does not display a tempo correction based on an uncertain assessment.

Business rules & product constraints

• The intended tempo is exercise-specific rather than a single universal speed.
• Tempo feedback is intended to influence the trainee's movement during the repetition, not merely provide a post-set measurement.
• Feedback should communicate an actionable adjustment rather than expose technical measurements.
• The system should prioritise reliable feedback over generating a correction when confidence is insufficient.

Out of scope

• Range-of-motion assessment
• Repetition counting
• R.I.R. estimation
• Post-set tempo statistics
• Overall workout scoring

What it looked like

This is the working prototype, not a mockup: a skeleton overlay tracking the movement, the rep counter and stage, a range-of-motion bar that fills and empties as the trainee moves through the repetition, and the correction appearing in real time as the form breaks.

Alongside the working loop I designed the interface for the fuller product: a home dashboard, a scheduled workout plan, the rest-timer analysis, a statistics view and workout history. The design question running through all of them was what a lifter can act on at each moment. Mid-set, the screen carries only what changes the current repetition, the rep count and stage, the range-of-motion bar and the corrections, all of it readable at a glance from across the room and none of it requiring a hand on the phone. Analytical detail such as R.I.R., time under tension and per-rep tempo would be noise at that moment, so it waits for the rest timer, when the trainee has eighty seconds and nothing to do with them. Matching the density of an interface to what the user can actually use right then, rather than to how much data the product happens to have, is a habit I have applied to every product since.

The business model for the camera version

Dropping the hardware invalidated the original model, which had leaned on equipment margin. I rebuilt it as a pure software model with four layers, each one unlocked by the one before it.

Three of those decisions are worth explaining, because they are the ones a fitness product usually gets wrong.

The coaching itself is free, across every exercise. The instinct is to paywall the thing that makes you special, and in most categories that is right. Here it is backwards. Nobody believes a phone camera can correct their squat until they watch it happen to them, so a hard paywall would be charging for a claim rather than for a product. Locking most of the exercise library behind that paywall fails for the same reason, so the free tier covers all of it. Industry benchmarks bear this out: freemium in health and fitness converts at roughly 2 to 3%, while free trials that let the user experience the product first convert far higher, up to around 49% for card-gated trials. In a category built on a claim people do not believe, the demonstration is the acquisition channel. What premium sells is not access to the coach, it is everything the coach can tell you over time.

Premium defaults to annual, with monthly still available. Both periods are offered, because forcing a year's commitment on someone who is not ready is a good way to lose them. Annual is pre-selected and carries a real discount, and that is not a pricing trick. Progressive overload, the thing the paid tier actually measures, only becomes visible over months. A monthly plan asks the user to renew before the product has had time to prove anything, and invites churn precisely when the value is about to appear. Annual billing aligns the billing period with the period over which the product justifies itself, which is also why health and fitness is the one category where annual plans dominate, at around 61% of revenue.

B2B sits third because it changes the product's shape, not just its price. A trainer can only physically stand next to one client at a time, so per-seat licensing plus remote form review turns the same model into something that scales a trainer's capacity rather than competing with them. The aggregate insight layer sits last for the obvious reason: it does not exist as an asset until the layers above it have produced enough data to be worth anything.

The accelerator

OptimaLifts was selected into Compass Cycle, the year-long incubator track of ACEin, the Athens Center for Entrepreneurship and Innovation at AUEB, and completed it in 2024. It covered a year of customer discovery, business modelling and growth planning with mentors, milestone planning against a time plan, and regularly having to defend the roadmap to people with no reason to be polite about it.

What I took from it

• Put the uncomfortable criterion in the comparison table. Scoring "affordable and discreet" as a row is what turned abandoning our own hardware into a calculation instead of an argument. A constraint that lives only in someone's head loses to whichever option has the better slide, every time.
• Find the constraint that defines the product, then design everything around it. Here it was timing: feedback had to land inside the rep or it was worthless. Once that was clear, it settled the architecture, the scope and the interface without further debate.
• Write the honesty requirement into the acceptance criteria. "Say you cannot see the movement rather than guess" is a product decision, not an engineering one. Leaving it unwritten means it gets traded away the first time someone wants a smoother demo.
• A business model is a sequence, not a price list. Free coaching, annual premium, per-seat B2B, then data. Each layer exists because the one before it made it possible, and getting the order wrong is how products with good economics on paper still fail.
• What I would do differently: I validated the problem thoroughly and the willingness to pay hardly at all. I had injury statistics and a competitor matrix long before I had one person who had said they would pay for it. Now the pricing conversation happens in week one, not in the financial model.