Six of our apps live in the Health & Fitness category: BreathHold Coach, Easy Fasting, WaterTracker, Water Tracker Intake, Gym Tracker & Workout Planner, and Minimalist Running & Walking. Looked at from a distance, that can read as scattered — why not fold water tracking, fasting, and running into one wellness app with a bigger surface area instead of maintaining six separate App Store listings?
The honest answer is that we're not building one wellness platform and calling it six apps. We're placing six separate, small bets, and treating each app's real-world reception as the signal that tells us where to invest next.
A single-purpose app is a fast, cheap experiment
A focused app — one job, one core screen, minimal onboarding — is small enough to design, build, and get in front of real users quickly. That speed is the actual point. Instead of spending months building a multi-feature platform based on assumptions about what people want, we can ship a narrow water tracker in a fraction of the time and let its downloads, retention, and reviews tell us something a spec document never could: whether this specific job, on its own, is something people actually want solved.
Some of those bets do well. Some plateau. That's the expected outcome of testing several ideas instead of betting everything on one big one being right on the first try.
"Aren't you just competing with yourself?"
It's a fair question, and the answer is no — because the apps aren't competing for the same user in the same moment. Someone who searches "water tracker" is not, in that search, also evaluating fasting apps or running trackers. They have one specific need right now. Each app is built and listed to win that one specific search, not to be someone's one wellness app for life. A person can have three of our apps installed at once without any of them stepping on the others, because each one owns a narrow, distinct job.
What a bigger app would actually cost you
The alternative — one combined wellness app — sounds efficient, but it comes with real costs that don't show up until later: a single onboarding flow now has to explain multiple features instead of one, a single App Store listing has to communicate multiple value propositions in one subtitle, and a single codebase carries the complexity of every module even if a given user only ever touches one of them. Worse, if one module has a bug or a bad release, it puts the whole app's rating at risk instead of one narrow product's.
What we do with the signal
The data from each small bet feeds the next decision, not a merge into one app. A pattern that works well in one app — a particular onboarding flow, a way of presenting streaks, a notification cadence that doesn't annoy people — gets reused as a proven pattern in the next app, the same way the legal-reference apps share an engineering template. What doesn't transfer is the assumption that success in one narrow niche means we should now bolt that feature onto every other app in the portfolio.
Running six small, focused experiments instead of one large, unproven platform isn't indecision — it's a more honest way to find out what's actually worth building more of, before committing months to guessing.