In January 2025 I started building atlas.core, a health and fitness platform that tracks training, nutrition, hormones, recovery and AI coaching in one place. It runs on the web and on iOS, bills by subscription, has role-based access for trainers and clients, and works in English and Portuguese.
I built it alone, with no co-founder, agency or outsourced team, and it’s live in the App Store now. This is how it happened: the reason, the architecture choices, the tools, and the parts nobody warns you about when you ship solo.
Why I built it
I needed it myself.
I’d been losing weight for the better part of a year, and anyone who has done that seriously knows calories are only part of it. Hormones, sleep, training load, recovery, macros, body composition and blood work all interact with each other.
I was using seven apps. One for workouts, one for food logging, one for weight, one for sleep, one for blood work, one for habits, one for notes. My data was spread across all of them and none of them talked to each other, so I could never see the whole picture, because the whole picture didn’t exist anywhere.
I looked for one app that did it all and couldn’t find one. Every app was good at one thing and useless at the rest, and the ones that tried to do everything were bloated and built for a different kind of user.
So I built it. If it worked for me, I’d use it every day. If it worked for me and it was good, I’d let other people use it too.
I didn’t set out to build a startup. I set out to fix something that was driving me crazy, and the product came out of the frustration.
There was a second reason. I’d spent five years on the revenue side of B2B SaaS, in outbound systems, SDR teams, pipeline and closing. I understood the business pressure. I had never shipped software. Building atlas.core closed that gap, and it made me an operator who has stood on both sides of the wall. Most people either sell or build. The ones who do both see the whole loop.
The stack
The first trap for a solo builder is over-engineering the stack. I wanted to move fast and ship to web and iOS from one codebase.
- React and TypeScript for the web app, and as the base for mobile.
- Capacitor to wrap the web app in a native iOS shell. One codebase, two platforms.
- Supabase for Postgres, auth, realtime and storage. It did the work of a backend team.
- RevenueCat for App Store subscriptions. It handles receipts, entitlements and trial logic.
- Tailwind CSS for styling, with no design system to maintain.
The choice I’d defend hardest is Capacitor over React Native. React Native would have given me better native performance, and it would have forced me to hold two mental models, web and native, at the same time. Capacitor let me write one app and ship it to both. For one person, that trade is worth it.
How I used AI in the build
I used AI throughout the build, and almost never as autocomplete. Autocomplete suggests the next line. What I wanted was help turning a vague goal like “add role-based access” into concrete steps, catching edge cases before they became bugs, and reasoning through architecture trade-offs.
I described the role hierarchy (owner, trainer, client, viewer) and the AI helped me design the Supabase row level security policies that enforce it at the database level. RevenueCat covers the happy path for billing, but a subscription can expire mid-session, a user can downgrade, and Apple’s receipt validation can run late, and the AI helped me enumerate those states and write a handler for each. For translation, instead of a flat key-value file, we designed a context-aware system that handles Portuguese grammatical gender, number agreement and unit conversion.
I shipped features at a pace that felt like a small team. The decisions were still mine. The AI sped up the stretches between them.
Getting through App Store review
Building the app was the easy part. Getting it past Apple’s review was the hard part.
Apple rejected the first submission for “insufficient content.” The app worked, but the reviewer felt the onboarding didn’t show enough value before asking for a subscription. I added a full preview mode so people can explore the app without signing up, moved the paywall deeper into the experience, and added screenshots and descriptions so Apple’s team could understand the product.
The second submission went through. Eleven days from first submission to live, most of it spent refreshing App Store Connect and wondering what I’d missed.
What’s live today
- Training: workout logging with progressive overload tracking, automatic PR detection and volume analytics.
- Nutrition: macro tracking, meal logging, and calorie targets that adjust to training load.
- Recovery: HRV and sleep integration, a readiness score, and training load recommendations.
- AI coaching: recommendations based on the full loop of training, nutrition and recovery.
- Billing: monthly and annual subscriptions through RevenueCat, with trials.
- Roles: owner, trainer, client, viewer and admin, each with scoped data access.
- Languages: full English and Portuguese.
What I’d do differently
I’d design for the phone first. I built the web app and then adapted it for mobile, which meant retrofitting touch interactions, navigation and viewport constraints the whole way. Next time I start on the phone screen and scale up.
I’d ship the first version sooner. I spent too long on role-based access before checking that anyone wanted the product. The RBAC system is good, and it would have been just as good built three months later, after I had paying users.
I’d automate releases in week two instead of month three. Manual builds for web and iOS, with the deploy and TestFlight steps, ate hours every release.
What it changed
Building atlas.core changed how I do revenue work. Once you’ve shipped code you stop saying “the engineering team should” and start saying “the constraint is.” You understand why estimates slip, why scope creep is expensive, and why the distance between “works on my machine” and “live in the App Store” is so wide.
I won’t build every product I sell, and I don’t need to. Having been on both sides of the wall, I can translate between them, and that makes me better at the revenue job. Selling and building are two views of the same system.