Kineo case study | Mobile health system
A premium health system built to feel guided, credible, and sticky from the first tap.
Kineo combines onboarding, daily coaching, workout flow, grocery planning, food scanning, settings, customization, and premium conversion into one mobile-first product story. The product is strongest where each route supports the next one.
Overview
Kineo is strongest when the product promise, route map, and conversion story all reinforce each other.
Too many fragmented health tools
Most fitness products separate workout logging, food planning, scanning, and premium conversion into disconnected experiences.
One guided mobile system
Kineo ties onboarding, daily dashboard, workout flow, grocery logic, scanner capture, and account preferences into one narrative.
Higher trust and stickier loops
The product feels closer to a premium operating system for health instead of a single-purpose tracker with add-ons.
My role
I owned the product framing and the frontend shape of the system.
- Defined route roles across onboarding, app, scanner, studio, and premium conversion
- Shaped the premium wellness tone, hierarchy, and visual system
- Built and refined the actual frontend surfaces and interaction language
- Connected daily-use screens to the store and paywall instead of treating them as separate products
Snapshots
More of the product system, including lower-page flows and operational routes.
Project stack
The stack supports both a web product shell and a dedicated mobile build.
Web build
React 19, TypeScript, Vite, React Router, ESLint
Mobile build
Expo, React Native, React Navigation, Expo Camera, Notifications, Secure Store
Product services
Supabase, RevenueCat, Sentry, Async Storage, vector icons, haptics
Notable features
These are real routes and systems pulled directly from the current codebase.
Onboard, App, Store, Settings, Studio, Workout, Grocery, Camera, Profile, Paywall
The web build already maps route-specific product roles instead of collapsing everything into one screen.
Today, Coach, Fuel, Scan, Me
The mobile app keeps core daily behavior in a five-tab structure with dedicated stack routes layered above it.
Storefront, paywall, and profile-connected settings
Conversion is part of the product loop, with trial framing, plan comparison, and settings tied to active subscription state.
Directional KPIs
If I were shipping this into broader beta, these are the numbers I would watch hardest.
Target onboarding-to-dashboard completion within the first session.
Target repeat scan behavior strong enough to replace manual logging habits.
Target conversion from active weekly users once the trial and plan story are tuned.
Target retained weekly users by linking dashboard, workouts, fuel, and scanner loops.
Timeline
The product expands in a sensible order: credibility first, daily loop second, premium systems third.
Position the product
Onboarding, store, and premium framing establish what Kineo is before a user learns the full route map.
Build the daily loop
Dashboard, workout, grocery, and scan routes create the behavior engine that makes the app useful every day.
Deepen personalization
Settings, customization, profile state, and saved templates make the product feel increasingly tailored and premium.
Prepare for broader beta
Release routes, support tooling, screenshot studio, and submission notes help the app mature beyond prototype quality.
Architecture
The architecture mirrors the product: one shared system, multiple specialized surfaces.
Acquisition
Onboarding + Store + Paywall
->
Daily loop
Dashboard + Workout + Fuel + Scan
->
Personal layer
Profile + Settings + Saved looks
Web shell
React + Vite routes act as the product proof layer and a parallel experience for concept validation.
Mobile app
Expo + React Navigation turns the same product language into a dedicated daily-use mobile experience.
Service layer
Supabase, RevenueCat, Sentry, notifications, camera, and secure storage support auth, billing, logging, and feedback loops.
Hardest tradeoff
Kineo has to feel premium without burying the user in too many health, food, and settings controls at once.
The main tradeoff was deciding what deserved its own route versus what should stay embedded in the dashboard. I leaned toward more route clarity because it makes the system feel more believable, more premium, and easier to scale.
- Separate screens reduce overload at the cost of a broader navigation map
- Premium framing raises expectations, so every route has to feel deliberately authored
- Scanner and grocery lanes only work if they feel native to the same promise as workouts and coaching
What I would build next
If I kept pushing Kineo, the next step would be making the intelligence layer even more legible.
Wearable and recovery sync
Make readiness and training adjustments feel more obviously powered by real data inputs rather than static logic.
Family mode and shared planning
Push the grocery and meal engine into a more credible household product instead of a solo tracker companion.
Richer premium reporting
Use reports, progress narratives, and tailored recaps to make the subscription feel more obviously compounding.
Next case study
Jump from guided health into the darker, faster SimDex interface world.
Kineo is about support and structure. SimDex shows the other side of the range: live signal density, operator surfaces, and noir market flow.