Day 1: Building a Running App Focused on Progress, Not Exposure
I have wanted to build a running app for a while.
Not because there are no running apps.
There are already many good products in the fitness space. Strava, Nike Run Club, Garmin Connect, Apple Fitness, and several others have shaped the way people track activities, share progress, and stay motivated.
But I keep coming back to one product question:
What if a running app was designed around personal progress and privacy by default, instead of social sharing by default?
That is the idea I want to explore.
Photo from Unsplash.
The problem I want to solve
Many fitness apps are extremely useful, but they often feel like social networks first and training tools second.
The feed becomes central.
Sharing becomes expected.
Location data becomes part of the experience.
For some users, that is great. Social motivation can be powerful. Some runners enjoy sharing routes, receiving kudos, joining clubs, competing with friends, and documenting their progress publicly.
But not every runner wants that.
Some people just want to run.
They want to track their route, understand their pace, measure progress, set weekly goals, and improve over time without feeling pushed into a public feed.
The more I think about it, the more I believe there is space for a running app where the default experience is private, focused, and training-oriented.
Social features can exist.
But they should be optional.
Why privacy matters in running apps
Running apps deal with sensitive data.
A route is not just a line on a map.
It can reveal where someone lives, where they work, what time they usually train, what streets they use, where they feel safe running, and what patterns they repeat every week.
For everyday users, that already matters.
For military personnel, security teams, public figures, journalists, activists, or people in sensitive environments, it matters even more.
This is not a theoretical concern.
In 2018, Strava’s global heatmap drew international attention because public activity data could reveal sensitive military locations, including bases and routes used by personnel. More recently, reports have continued to show how public fitness activity can expose sensitive movements. In 2026, Le Monde and AP reported that a French naval officer’s public Strava activity helped reveal the location of the French aircraft carrier Charles de Gaulle during a deployment.
I am not bringing this up to attack Strava.
Strava is a successful product for a reason. It created a powerful community around endurance sports.
But these cases highlight an important product lesson:
When location is involved, privacy cannot be treated as an afterthought.
The product direction
The app I want to build starts from a simple principle:
The user should be in control of what is tracked, what is stored, and what is shared.
The core experience should be about running and improving.
The social layer should be available, but not forced.
At a high level, the first version would focus on:
- tracking runs
- recording routes
- measuring distance, time, and pace
- setting weekly goals
- reviewing personal progress
- comparing current performance against past performance
- keeping activities private by default
- allowing users to share only when they explicitly choose to
The goal is not to build a “Strava clone.”
The goal is to build a running-focused product with a different philosophy.
Initial product hypothesis
My first hypothesis is:
There are runners who want a focused training app with privacy-first defaults and optional social features.
That breaks down into a few smaller assumptions:
- Some users want to track runs without automatically participating in a social feed.
- Weekly goals are more motivating for many beginners and intermediate runners than complex performance dashboards.
- Route tracking is valuable, but route sharing should be intentional.
- A clean personal progress view can be more useful than a crowded social timeline.
- Privacy settings should be simple, visible, and understandable from the beginning.
- Social motivation should exist as an option, not as the default product behavior.
Those assumptions may be right.
They may be wrong.
That is why this starts with requirements and product thinking before writing code.
Day 1: Requirements gathering
For Day 1, I am starting with the product definition.
Before designing screens or choosing the tech stack, I want to define what the MVP should actually do.
Core user stories
Here are the first user stories I am considering:
As a runner, I want to record a run so that I can track my distance, time, route, and pace.
As a runner, I want my activities to be private by default so that I do not accidentally expose my location.
As a runner, I want to set weekly goals so that I can stay consistent.
As a runner, I want to review my progress over time so that I can see if I am improving.
As a runner, I want to decide when to share an activity so that sharing is intentional.
As a runner, I want a simple dashboard so that I can quickly understand my training week.
MVP features
For the first MVP, I would keep the scope intentionally small.
The initial feature set could be:
- Account creation
- Run tracking
- GPS route recording
- Activity history
- Weekly goal setting
- Basic stats: distance, time, pace
- Private activities by default
- Optional activity sharing
- Basic profile
- Simple progress dashboard
Everything else should wait.
No complex clubs.
No public leaderboards.
No achievement overload.
No over-engineered training plans at the beginning.
Just the core loop:
Run -> Track -> Review -> Improve
Privacy-by-default requirements
This is the part I want to take seriously from the start.
Some early requirements:
- New activities should be private by default.
- Sharing should require a clear user action.
- The user should be able to hide start and end points.
- The app should clearly explain what data is being stored.
- The app should make privacy settings easy to find.
- The user should be able to delete an activity.
- The user should be able to disable social features.
- Public profiles should not expose sensitive location patterns by default.
A privacy-first product is not just about adding a settings page.
It is about making safer defaults part of the product architecture.
Design direction
Visually, I want the app to feel calm, focused, and performance-oriented.
Not noisy.
Not feed-first.
Not overly competitive.
The first screens I want to explore are:
- onboarding
- privacy preferences
- home dashboard
- start run screen
- live run tracking
- post-run summary
- weekly progress
- activity history
- optional share screen
The main design challenge will be balancing simplicity with useful training data.
Too little data and the app feels basic.
Too much data and it becomes overwhelming.
Technical direction
I have not fully decided the stack yet, but I am thinking in terms of a mobile-first product.
The app needs:
- reliable GPS tracking
- background activity recording
- route storage
- authentication
- user preferences
- activity history
- privacy controls
- possibly offline support later
I will evaluate the technical approach after the first design and requirements pass.
For now, the priority is not the framework.
The priority is defining the right product.
What I want to validate
Before building too much, I want to validate a few questions:
- Do runners actually care about privacy-first defaults?
- Would beginners prefer weekly goals over complex training plans?
- Is optional social sharing enough, or is the social layer essential for retention?
- What stats matter most after a run?
- Would users trust a new app with location data if the privacy model is clear?
- What is the smallest version of this product that still feels useful?
These questions will guide the MVP.
Why I am building this in public
I want to document the process from the beginning:
- product thinking
- requirements
- UX decisions
- design iterations
- technical tradeoffs
- MVP scope
- mistakes
- lessons learned
Building in public forces clarity.
It also creates accountability.
More importantly, it shows the actual process behind building software: not just the final screens, not just the code, but the decisions that shape the product.
The principle for this project
If I had to summarize the product in one sentence, it would be this:
A running app where progress is the core experience, and sharing is a choice.
That is the direction.
Day 1 is not about writing code.
Day 1 is about understanding the problem well enough to avoid building the wrong solution.
Next step: define the first user flows and start sketching the MVP experience.