What I Learned Building for the Person Who Has a Real Life

Most fitness products get built around an imaginary person.

This person sleeps eight hours a night. This person preps meals on Sunday. This person works near a gym, keeps a stable schedule, and follows a twelve-week plan without a single interruption.

I spent a long time looking for this person. I never found them.

What I found instead were people whose lives kept overriding their plans. A parent whose kid got sick on leg day. A shift worker whose schedule changed weekly. A traveler who landed in a city with no equipment and a rainstorm outside.

When I started building FitPocket, I made a decision that shaped everything after it: design for the person whose life refuses to cooperate. This article is a reflection on what that decision actually cost, and why the choices that look obvious now required real conviction at the time.

The Industry Built for Compliance and Called It Coaching

Here's what I noticed when I studied how fitness products fail.

The dominant model works like this: the app hands you a plan, and your job is to execute it. When you execute, the app celebrates you. When you miss a session, the app sends a reminder. When you miss three, it goes quiet, and eventually you delete it.

The industry read this pattern as a motivation problem. Build better streaks. Add badges. Send push notifications at 6am.

I read the same pattern differently.

People weren't failing the plan. The plan was failing to account for their lives.

A program that assumes stable conditions breaks the moment conditions change. Weather shifts. A meeting runs long. Your knee acts up. The plan has no answer for any of this, so the gap between the plan and reality lands on you. You absorb it as guilt.

This is commonly overlooked, and I think it explains more churn than any pricing page ever will. When a system demands willpower to maintain, the system is broken. Willpower is a finite resource, and asking users to spend it covering for your product's rigidity is a design failure dressed up as a discipline test.

Three Decisions That Looked Wrong Before They Looked Obvious

Once you accept that real lives are the terrain, several design decisions follow. Each one felt risky at the time. Each one drew skepticism. I want to walk through three of them honestly.

1. Treating context as a first-class input

Weather. Location. Available equipment. Schedule collapse.

Most products treat these as edge cases. Something to handle in version four, after the core experience ships. I made them the core experience.

If it rains and your workout was an outdoor run, the system adjusts before you open the app. If you're in a hotel with two dumbbells and a bench, the session rebuilds itself around what's actually in the room.

The pushback I heard was consistent: this adds complexity, users just want a plan. Here's what I learned. Complexity in the architecture removes complexity from the user's day. Someone has to absorb the variance of real life. Either the system absorbs it, or the user does. I chose the system.

2. Building for conversation instead of menus

A person mid-workout, or mid-commute, or holding a toddler, does not want to navigate five screens to log a substitution.

So voice and text became core infrastructure from day one. You tell the system your shoulder hurts today, and it adapts the session. You ask why an exercise got swapped, and it explains.

Conversational input looked like a gimmick to a lot of people in 2022. Chatbots had a bad reputation, mostly earned. The conviction required here was believing that accessibility is intelligence. A system you can talk to while your hands are full serves the messy life. A system that demands taps and forms serves the idealized one.

3. Tracking beyond the vanity number

Weight on a scale is one signal, and a noisy one. Real progress is multidimensional.

FitPocket tracks body scans, measurements, photos, and trends together, because a person whose weight held steady while their measurements shifted is making progress the scale will never show them. Showing them that progress keeps them in the system during the weeks when the single number would have pushed them out.

Data without context is noise. Context without action is theater. The tracking layer exists to connect the two.

The Hardest Part Was Saying No to the Obvious Roadmap

I want to be honest about the cost of this approach, because founder reflections that skip the cost aren't worth much.

Every design review, there was pressure to build the conventional thing. Streaks. Leaderboards. A rigid twelve-week program with a marketable name. These features demo well. Investors recognize them. They photograph nicely in an app store listing.

Adaptive infrastructure demos poorly.

The whole point of an adaptive system is that it works invisibly. When the weather adjustment fires correctly, the user never notices anything happened. When the meal plan flexes around a dietary preference, whether vegetarian, vegan, pescatarian, or omnivore, it just looks like a normal Tuesday. Intelligence works best when the user never has to think about it.

You can't screenshot invisibility. That made every one of these decisions harder to defend in the moment and easier to defend in retention data six months later.

There was also the global question. Building for 175+ countries from day one means designing for variance in equipment, climate, food culture, and daily rhythm before you have the revenue to justify it. The conventional advice says nail one market first. I decided that a system built to handle variance had to prove itself against variance from the start. A product that only works in controlled conditions is a lab result, and lab results don't survive contact with a shift worker in a different hemisphere.

What This Says About Product Design Beyond Fitness

I think the lesson here extends past my category, and I want to name it carefully.

Every industry has its version of the idealized user. Finance apps assume steady income. Productivity tools assume uninterrupted focus blocks. Education platforms assume evenings free for study. The people who match these assumptions are a small slice of the actual market. Everyone else adapts themselves to the tool, struggles, and quietly churns.

The underserved market is almost always the people whose reality the product refused to model.

Here's the practical version of that insight, the one I'd offer any builder:

• Audit your assumptions about stability. List every condition your product needs to be true for a user to succeed. Each item on that list is a churn risk.
• Move edge cases to the center. The interruptions you're deferring to a later version are the daily reality of most of your users.
• Measure what the user absorbs. Every gap between your system and their life gets paid for by someone. Track who's paying.
• Accept that the best work is invisible. Retention will show what screenshots can't.

When a product finally models someone's real constraints, something interesting happens in how they talk about their past. People stop defending their old failures and start recognizing them as system failures. The shame leaves the room. Architecture did that, and I find that more durable than any pep talk a product could deliver.

Where the Conviction Points Next

Fitness is where I started because fitness is where the gap between intention and execution is most visible. It shows up in every abandoned membership and every deleted app.

The deeper project is the gap itself.

Any goal that requires sustained behavior change runs into the same problem: aspiration gets planned in ideal conditions and executed in real ones. The layer that closes that gap through design will matter across far more domains than workouts and meals.

I build systems that meet people where they are. That sentence sounded like a compromise to some people early on, as if meeting people where they are meant lowering the bar.

I've come to believe the opposite of a compromise happened. Meeting people where they are is the highest engineering standard I know, because reality is a harder spec than any lab condition. The decisions look obvious now. They were available to everyone. The conviction to build for the messy life before the market validated it was the actual product.

If you're building something, look hard at who your assumptions quietly exclude. That's where your next decade of work is hiding.