Overview
Strong Foundation is a cross-platform wellness application that brings workouts, nutrition, routines, cardio tracking, personal health records, and community content into one connected experience.
I have been working on Strong Foundation in my spare time since 2020, and like many of my projects, it started with frustration.
At the time, I had recently changed my eating habits and started following a ketogenic diet. I used Samsung Health to track meals, calories, weight, and the data coming from my Galaxy Watch. I used another application to build and record my strength-training workouts.
Both apps worked well independently. The problem was that they did not work together.
If I wanted an accurate picture of my health, I had to manually copy information between applications or accept that each one only knew part of the story. Eventually, I did what most people do when tracking becomes more work than the activity itself: I stopped consistently entering the data.
So naturally, instead of continuing to use two apps, I decided to spend the next several years building one.
Only a software engineer would consider that the easier option.
From Fitness Tracker to Wellness Platform
The first version of Strong Foundation focused on the immediate problems I was trying to solve:
- Creating and recording custom workouts
- Tracking calories and body weight
- Defining diets and dietary restrictions
- Finding and presenting recipes
- Building meal plans and grocery lists
- Synchronizing selected records with external health platforms
The goal was not simply to place several unrelated tools inside the same application. Each experience needed to remain useful on its own while still being able to work with the rest of the system.
A recorded workout could contribute to the user’s daily calorie totals. A weight goal could help determine calorie targets. Those targets could influence recipe recommendations and meal planning. A routine could combine workouts and recipes into a schedule that someone could follow throughout the week.
Strong Foundation gradually expanded into cardio and GPS tracking, water consumption, menstrual and pregnancy tracking, meditation and journaling, achievements, community posts, direct messaging, Spotify integration, and tools for creating and sharing workouts, recipes, and routines.
Did the scope become much larger than I originally planned? Absolutely.
But the larger product also exposed the real engineering problem behind Strong Foundation: personal wellness is not one feature. It is a collection of related decisions, records, habits, and services that rarely speak the same language.
Privacy Became an Architectural Decision
As Strong Foundation grew, privacy became just as important as the features themselves.
A wellness application can know what someone eats, where they run, how much they weigh, what health events they record, and what goals they are trying to reach. That information can create a great user experience, but it can also become an unnecessarily detailed profile of a person.
I did not want Strong Foundation’s business or architecture to depend on collecting every piece of information it could get its hands on.
Instead, many of the personal tracking features use local databases on the user’s device. Health-platform integrations are permission-based and only participate when the user chooses to connect them. The backend is primarily responsible for accounts, shared content, community features, messaging, notifications, and the information needed to support those experiences.
This creates more work.
When a user does not connect Apple Health, Health Connect, or Fitbit, Strong Foundation still needs to function. That means providing first-party tracking experiences, storing records locally, calculating values on the device, and handling cases where certain information is unknown.
It would be easier to send everything to a server and let the backend become the source of truth. Easier, however, does not always mean better.
Strong Foundation’s architecture is built around minimizing what needs to travel across the network while still supporting the experiences that genuinely require a shared service. User-created content also supports visibility controls, allowing supported posts, recipes, routines, and workouts to be public, unlisted, or private.
Direct messaging introduced another privacy-sensitive problem. Messages are designed around per-device encrypted payloads, which allows each registered device to receive content intended for it without treating the server as the obvious home for plaintext message bodies.
I would not call the application magically private or claim that every security problem has been solved. Privacy is not a badge that gets added to the settings screen. It is an ongoing engineering constraint that affects data models, storage, permissions, defaults, synchronization, and product design.
Making Different Health Platforms Agree
The largest technical challenge has been synchronizing information between Strong Foundation and third-party health ecosystems.
The original Android application worked with Samsung Health, Fitbit, and Google Fit. Over time, the platform landscape changed. Android moved toward Health Connect, while the iOS application integrated with Apple Health. Fitbit continued to have its own API, authorization flow, record formats, and limitations.
On paper, health data sounds straightforward. Weight is weight. Distance is distance. Calories are calories.
In practice, each provider represents data differently.
They may use different units, identifiers, permission models, date formats, record types, and expectations around updates or deletions. One provider may allow an application to write a certain record while another only allows it to be read. Some records belong to a workout session, while others exist as independent samples. Even determining whether two records describe the same event can become a problem.
Strong Foundation needs to translate between those systems without exposing that complexity to the user.
Internally, the application works with its own domain models. Conversion happens when information is read, written, or displayed. Values can remain in the appropriate native or canonical units while the user sees pounds, kilograms, miles, kilometers, ounces, or liters according to their settings.
The synchronization layer also has to remember which records originated from which provider. Otherwise, the app risks duplicating information, writing the same record repeatedly, or attempting to delete something from the wrong system.
This is not the type of work that looks exciting in a screenshot, but it is the work that determines whether someone can trust the numbers on the screen.
Cross-Platform Does Not Mean Copy and Paste
Strong Foundation currently spans a native Kotlin Android application, a React Native and TypeScript iOS application, a Node and Express backend, and a React-based web companion.
The Android and iOS apps aim to provide the same overall product, but they do not share every implementation detail. Each platform has its own health APIs, permission systems, background-processing rules, secure-storage options, and lifecycle constraints.
Android uses Health Connect, Kotlin, MVVM-style architecture, repositories, RxJava, Retrofit, Koin, and local SQLite storage. The iOS port uses React Native, TypeScript, Redux Saga, SQLite, secure device storage, and Apple HealthKit.
The backend is built with TypeScript, Express, Mongoose, and MongoDB. It provides authentication, user profiles, workouts, recipes, routines, community content, messaging, assets, notifications, achievements, and the newer content-access system. Socket.IO supports realtime conversation events, while background services handle scheduled and asynchronous work.
The web companion uses React and Express to provide public pages and newer browser-based content creation and reading experiences.
The hardest part of cross-platform development has not been making two screens look similar. It has been maintaining the same rules and expectations across several independently evolving systems.
What does a private routine look like on Android, iOS, the web, and the API? How does each client interpret a locked-content response? What happens when an older mobile version encounters a newer content model? Which application owns the conversion of a health record? How does a draft survive an application restart?
Feature parity is really contract parity.
That requires shared concepts, carefully designed API responses, compatible models, database migrations, and tests that catch differences before users do.
Rebuilding the Content System
One of the largest recent investments has been rebuilding how user-created content works.
Strong Foundation originally treated community posts, recipes, routines, and workouts as mostly separate features. That worked while the application was smaller, but it became limiting as users gained the ability to attach content, mention other users, add topics, control visibility, and reference one type of content from another.
A routine may contain both recipes and workouts. A community post may reference a recipe. A profile may need to display several types of content in one feed. A private item may expose a preview without exposing the full data.
The newer content architecture moves these features toward a shared content graph. Content can use common attachments, entity references, topic tags, rich text, access settings, and author information while still retaining the fields that make a recipe different from a workout.
This work also required migration paths for older records and compatibility layers for clients that still understand the original models.
Long-running products collect history. Eventually, maintaining that history becomes a feature of its own.
Role
I am the product designer and primary independent engineer behind Strong Foundation.
My work includes mobile and web implementation, backend API design, database modeling, health-platform integrations, privacy and access-control architecture, local persistence, realtime messaging, background services, testing, CI/CD, and deployment support.
Because this is a product I have maintained for several years, the role also includes the less glamorous parts of software development: migrating old models, replacing deprecated integrations, fixing production issues, improving build pipelines, and deciding which ideas should not be built yet.
Stack
Android: Kotlin, Android Views and Fragments, MVVM, Koin, RxJava, Retrofit, SQLite, Health Connect, Fitbit, Mapbox, Firebase, and Socket.IO.
iOS: React Native, TypeScript, Redux Saga, SQLite, secure device storage, Apple HealthKit, Fitbit, Mapbox, and Socket.IO.
Backend: Node.js, TypeScript, Express, Mongoose, MongoDB, Passport, JWT authentication, Socket.IO, Redis-backed services, background jobs, push notifications, and object-storage integrations.
Web: React, TypeScript, Bootstrap, React Router, Express, and server-side rendering.
Quality and delivery: Jest, Kotest, Android instrumentation tests, UI workflows, GitLab CI, database upgrade services, and release-oriented mobile pipelines.
Status
Strong Foundation is an active, long-running product with released Android and iOS applications, a broad backend API, and a newer web companion.
Many of its core experiences are implemented and usable, including workouts, recipes, routines, personal tracking, cardio, women’s-health tracking, health-platform synchronization, community content, and direct messaging.
That does not mean every feature is complete or equally mature.
The application has grown through several generations of architecture, which means older models and screens still exist beside newer content builders and access-control systems. Platform parity is an ongoing effort rather than a one-time milestone. The content, monetization, moderation, accessibility, and privacy experiences still have areas that need to be hardened before I would consider the broader vision complete.
Strong Foundation is best described as an ambitious, release-oriented product that continues to evolve—not a finished application placed on a shelf.
Next Steps
The immediate focus is hardening content creation across Android, iOS, and the web. The newer builders need to provide consistent rich-text editing, attachment handling, drafts, mentions, topic tags, and visibility controls without losing content or producing different results on each platform.
The privacy model also needs continued investment. Users should have clearer control over what is stored locally, what is synchronized with a health provider, what is shared with the Strong Foundation community, and who can access the content they create.
Once those foundations are stronger, the next challenge is attracting more people to the application. Strong Foundation has spent most of its life as a project built in my spare time and shared within a relatively small community. A larger marketing effort will help determine which parts of the product solve real problems for people outside of my immediate circle.
Finally, Strong Foundation needs a sustainable way to fund its continued development. That may include paid ad-free access, premium capabilities, or tools that allow creators to monetize useful routines and content. Whatever direction that takes, I do not want private health behavior to become the product.
Strong Foundation started because I was tired of entering the same information into multiple apps.
Several years, multiple mobile clients, a backend, a web companion, several health integrations, and more database migrations than I care to count later, the original goal is still the same: make it easier for people to manage their wellness without giving up control of their information.
The application still has plenty of growing left to do, but then again, that is the point of building a strong foundation.