How Musclog Rebuilt a Fitness App: Design System, AI-Generated UI, and a Privacy-First Architecture

Table of Contents

1. Key Highlights
2. Introduction
3. From patched UI to a design system: why the rebuild started
4. Using AI to design the new UI: Google Stitch and the discipline of describing intent
5. NativeWind and the advantages of a utility-first rebuild
6. Local-first architecture: WatermelonDB, reactive queries, and encryption
7. Cross-platform rendering for charts: Victory Native, Skia, and web fallbacks
8. Tracking training volume correctly: averaging 1RM formulas and RIR
9. Rebuilding food tracking: public datasets, mapping, and multi-source search
10. Loggy: an AI coach that understands your data
11. Weekly check-ins and empirical TDEE estimation
12. Privacy-first distribution and the business model debate
13. Small but meaningful features: widgets, cycle-aware recommendations, export/import
14. Planned improvements: onboarding, BLE scales, and iOS considerations
15. Lessons for builders: practical takeaways from Musclog's rebuild
16. Where to try it and how to contribute
17. FAQ

Key Highlights

• Musclog moved from ad-hoc UI and mounting UX debt to a disciplined design system and Tailwind-style styling, using an AI design tool to crystallize product intent.
• The app is local-first: WatermelonDB-backed storage, AES encryption for health data, dual-render charts, and public food databases (USDA + Open Food Facts) enable robust offline use without recurring server costs.
• Advanced features include an LLM-powered coach with strict schema enforcement, photo-based meal estimation, barcode/OCR scanning, empirical weekly check-ins that infer real TDEE, and a commitment to a non-subscription distribution model for Android.

Introduction

A ninety-second gap between sets can tell you more about an app than months of usability tests. When a developer finds themselves fumbling through four taps to log a set in the app they built, the problem is not some minor annoyance—it is a direct attack on the product’s purpose. That was the moment Musclog's creator decided to dismantle the interface, rethink the architecture, and rebuild everything properly.

What began as a functional but visually inconsistent side project evolved into a fully reworked fitness tracker: a coherent UI driven by a design system, a local-first data layer built for reliability and privacy, improved food-tracking powered by public datasets, and AI features that are integrated with the user’s own data rather than generic advice. Musclog’s rebuild is a useful case study for any developer or product manager wrestling with technical debt, cross-platform complexity, and the trade-offs between convenience and user privacy.

Below is a deep look at the technical and product decisions that took Musclog from a “works-but-ugly” experiment to a polished, privacy-conscious tool people actually use.

From patched UI to a design system: why the rebuild started

Initial versions of many side projects begin with momentum and improvisation. Components get dropped in where they make sense at the moment; colors are chosen by “vibes”; spacing and radii are inconsistent. Musclog was no different. Built with react-native-paper, the app functioned—but it looked and behaved like several different apps glued together.

That patchwork approach produced clear symptoms:

• Primary actions had inconsistent sizes and placement.
• Cards and inputs used different corner radii with no rationale.
• Colors were hardcoded everywhere, leading to accidental variations.
• Navigation flows included steps that existed only as UI-level workarounds for technical constraints.

These symptoms create what product teams call UX debt: small frictions that accumulate into a seriously degraded user experience. The decisive move was to accept the cost of a full rebuild to eliminate that compounding friction.

The migration plan had two parts: swap the component library to a utility-first styling system (NativeWind, the Tailwind-like framework for React Native) and formalize a design system that prescribes spacing, colors, radii, and semantic components. That work sounds simple until you remember the codebase size and the number of screens dependent on the current layout—then it becomes a significant engineering task. The return is consistent UI, fewer visual regressions, and a much faster future development path.

Using AI to design the new UI: Google Stitch and the discipline of describing intent

Rather than attempt to redesign the interface purely by hand, the developer experimented with Google Stitch—an AI-driven generator that converts prompts and reference images into coherent mobile UI components. This choice was not about outsourcing creativity; it was about forcing clarity.

To generate useful screens, you have to answer two questions: what is this screen for, and what should the user be able to do here? Answering that in detail is a product exercise. Stitch then translates the intent and references into a cohesive visual language. The output that resonated was labeled “Kinetic Depth”: deep greens for surfaces, indigo-to-emerald gradients for primary actions, and large numerals where numbers matter most (weights, reps, calories).

The AI-generated UI also compelled the author to write specifications for the first time on this project: semantic color names (e.g., protein = indigo, carbs = emerald), spacing scale (4/8/12/16/20/24/32 px), and radius standards (12px for inputs, 16px for primary cards). Those rules eliminated subjective choices and made future components predictable.

Beyond visuals, the Stitch-driven process uncovered deeper UX problems. An extra step in the workout logging flow existed solely because of a prior technical shortcut. The act of describing the desired UI forced a redesign of the underlying service to remove that workaround. Using an AI tool to prototype visuals turned out to be an efficient way to unearth product-level inconsistencies.

Real-world takeaway: an AI UI generator can accelerate design decisions—but its most valuable effect may be the discipline it imposes on product thinking.

NativeWind and the advantages of a utility-first rebuild

Switching to NativeWind (Tailwind CSS for React Native) unlocked consistent styling and a single source of truth for visual rules. Utility classes reduce repetition, make it easier to refactor layout across many screens, and play nicely with a design system that defines spacing and color semantics.

Benefits realized:

• A small set of utilities expresses the majority of layout and spacing choices, reducing the chance of drift across screens.
• Theming and semantic colors make it trivial to change the app’s look or introduce a light theme later.
• New components follow a clear contract: predictable spacing, heights, and radii.

This approach contrasts with the original “slap components together” workflow that encouraged divergent visual decisions. It also makes future contributions simpler: when every contributor understands the spacing scale and the color semantics, UI changes are consistent by default.

Local-first architecture: WatermelonDB, reactive queries, and encryption

Rebuilding the interface was also an opportunity to tighten the data architecture. Musclog adopted WatermelonDB as the local data layer. WatermelonDB provides a model layer on top of SQLite for native and LokiJS for web, with reactive queries that cause the UI to automatically re-render when observed data changes.

Why WatermelonDB matters:

• Reactive queries eliminate many "did I remember to refresh?" bugs.
• The same model layer works across Android and web, simplifying development and testing.
• Atomic operations and batching decrease the likelihood of inconsistent writes.

Practical discipline matters when using WatermelonDB. The project enforced a rule: every database write must be executed through a single write block (database.write(async () => { ... })). Nested write blocks deadlock; strict team conventions avoid those production-time frustrations. For multi-insert operations, the prepareCreate + database.batch() pattern creates multiple records atomically within one write block, avoiding multiple round trips.

Security was a priority. Health data—weight history, body fat percentages, nutrition logs—are AES-encrypted before being persisted. The encryption logic is centralized in a helper module that transparently encrypts on write and decrypts on read. The encryption key is derived per device and never leaves it. That design makes the encryption an implementation detail for features and contributors while protecting sensitive data in the local store.

Real-world benefit: users can use the app offline, and if someone extracts the raw SQLite file, the most sensitive fields are encrypted. For many users, a local-first model with device-level encryption is more private than a cloud-first service.

Cross-platform rendering for charts: Victory Native, Skia, and web fallbacks

Visualizing workout progress and nutrition trends requires charts. On mobile, Musclog uses Victory Native, which renders with Skia. Skia offers performant native graphics. On web, Skia isn’t available, so the app uses Victory with SVG. The practical solution is to implement a single LineChart component with two runtime-specific files: LineChart.tsx for native and LineChart.web.tsx for web. The bundler resolves the right file automatically.

That pattern keeps the consuming components simple: identical props and behavior regardless of platform. It doubles the implementation effort for charts but prevents silent breakage on web and keeps the core UI code platform-agnostic.

Another cross-platform challenge was OCR and barcode scanning. Native platforms use device ML (e.g., ML Kit), while the web uses tesseract.js. Each engine has different initialization and lifecycle requirements, so the same dual-file trick keeps the public API consistent while letting each runtime use its best option.

Real-world lesson: platform differences often justify separate runtime modules, but the consumer-facing API should remain consistent.

Tracking training volume correctly: averaging 1RM formulas and RIR

A naive volume metric—weight × reps—misses fundamental differences between set compositions. Musclog tracks "volume" using estimated one-rep max (1RM) rather than raw tonnage. Estimating 1RM is not straightforward: multiple formulas exist (Brzycki, Epley, Lander, Mayhew, etc.), and none is universally accepted.

Musclog computes all seven commonly used 1RM formulas and averages them. The user can optionally provide RIR (Reps in Reserve), which adjusts estimates upward if the set was performed with more reps available. That provides a better proxy for training stimulus across varied sets. Averaging multiple 1RM formulas reduces sensitivity to the arbitrary choice of a single formula and produces a smoother, more robust volume time series.

This design decision recognizes the messiness of biological data and avoids false precision. For developers building training metrics, averaging established estimators and accounting for subjective intensity (RIR) often yields more useful insights than choosing one formula and treating its output as gospel.

Rebuilding food tracking: public datasets, mapping, and multi-source search

Food tracking is a common pain point in fitness apps. Many commercial apps gate high-quality food databases behind paywalls or proprietary APIs. Musclog’s approach uses public datasets—USDA FoodData Central and Open Food Facts—to provide deep nutritional detail without subscription fees.

USDA FoodData Central

• A comprehensive, government-maintained database covering raw ingredients and many branded items.
• Nutrients are identified by numeric codes; Musclog maps those to human-readable fields.
• Provides rich macro and micronutrient breakdowns.

Open Food Facts

• Community-driven, global coverage of packaged products with barcode support.
• Crucial coverage for products that a US-centric database misses.
• Crowdsourced models are not perfect, but they dramatically increase the app’s global usefulness.

Search strategy: Musclog queries both APIs in parallel and merges results into a single list. Abort controllers prevent stale responses from clobbering newer results. The user interacts with a unified search UI and need not know which backend produced each item.

Barcode scanning and OCR

• Barcode lookups query Open Food Facts for near-instant product matches.
• OCR uses device ML on native and tesseract.js on web. Language packs support English, Spanish, Portuguese, Dutch, German, and French to cover diverse packaging.
• For ambiguous meals (restaurant food, composed dishes), Musclog provides OCR label scanning and AI-based photo estimation where scanning isn’t possible.

Why this matters: a robust food database plus frictionless logging (barcode scanning, OCR, AI estimation) makes nutrition tracking usable day-to-day. The ability to see 40+ micronutrients produces insights that matter—users often discover consistent deficiencies (e.g., magnesium) only when the data exists.

Practical cost angle: because the data sources are public and the processing happens on-device, there is no technical reason for a nutrition database to require subscription revenue.

Loggy: an AI coach that understands your data

Basic chatbots are common in apps today, but Musclog’s AI coach—Loggy—differs because it connects meaningfully to the user’s stored data. Instead of generic advice, Loggy answers questions by synthesizing the user’s recent workouts, nutrition logs, weight trends, and goals.

Two technical problems required careful design:

1. Structured model output: LLMs will often produce prose that looks structured but breaks parsers. Musclog’s solution is a utility that takes a JSON schema and enforces strict rules (additionalProperties: false and required fields) recursively. This strict schema goes into the function-calling configuration so the LLM must return exactly the expected shape or fail cleanly.
2. Data privacy and API costs: the AI calls run through the user’s own OpenAI or Google Gemini API key. Musclog does not broker those calls; the user pays model usage directly if they choose to use Loggy. The app stores AI prompts and custom instructions locally so behavior can be tweaked without code changes.

Loggy includes a photo-analysis flow: take a picture of your meal, the model estimates portion sizes and nutritional content, then the user confirms before logging. That last step is vital—the AI proposes, the user decides.

Real-world implications: an AI assistant that reads and reasons over personal data is more helpful than one that only produces general advice. Strict schema enforcement is the engineering trick that transforms an intermittently useful prototype into a reliable feature.

Weekly check-ins and empirical TDEE estimation

Musclog’s weekly check-ins are a low-friction way to surface meaningful signals. Every week the app computes a 7-day rolling average for weight, caloric intake, and activity, producing a status: On Track, Ahead, or Behind. The system evaluates "trend" (weight change relative to target) and "consistency" (what percentage of days had food logged). That helps distinguish between real variance and missing data.

TDEE (total daily energy expenditure) estimation takes an empirical approach. Instead of relying solely on formulaic BMR estimates and multiplers (Harris-Benedict, Mifflin-St Jeor), Musclog looks at actual logged calorie intake and observed weight change over time to infer maintenance calories. For example, if someone logs 2,200 kcal/day and loses 0.3 kg/week, the app uses that relationship to estimate a realistic maintenance number instead of a default formula that often mischaracterizes folks with atypical activity profiles.

A subtle but important detail: the code uses asymmetric constants for gaining versus losing weight (building fat costs more energy than merely burning it). The system uses empirically supported energy-per-kg constants (e.g., ~8840 kcal/kg to build vs ~7730 kcal/kg to lose) rather than a single flat 7,700 kcal/kg. That asymmetry matters when small signals are being leveraged to adjust goals; it reduces systematic bias and improves the sensitivity of recommendations.

Real-world benefit: weekly check-ins reveal when a plan is not matching reality and can automatically recalculate nutrition goals based on actual behavior instead of adhering to a hypothetical plan that the user never reached.

Privacy-first distribution and the business model debate

A recurring pattern across consumer fitness apps is the creep of features behind a paywall. Companies often launch with a free tier then migrate essential features to subscription plans. Musclog intentionally avoids that path by designing an app that requires no server infrastructure: data lives on the device, public food databases are free, and AI calls (if used) are executed through the user’s own credentials.

Why this matters:

• No server costs means no pressure to introduce subscriptions to cover running expenses.
• Users retain ownership and control of their data by default.
• An offline-first experience ensures the app remains functional in gyms, basements, and travel scenarios with poor connectivity.

Licensing and sustainability: the code is open source under an Attribution-NonCommercial-NoDerivatives 4.0 International license. That allows personal use and inspection but prevents commercial derivatives from being redistributed without permission. The developer notes that if a paid model is ever required to cover distribution costs (notably Apple’s annual $100 developer fee for the App Store), the plan would be a one-time purchase rather than a subscription—pay once, app is yours. The Android distribution model remains free for now.

Real-world context: If you’ve used apps that put core features like macro targets or progress charts behind a paywall, you recognize the frustration that motivates a local-first, non-subscription approach.

Small but meaningful features: widgets, cycle-aware recommendations, export/import

Beyond the headline features, several pragmatic additions improve long-term usability:

• Home screen widgets for quick logging and daily summaries reduce friction for small interactions.
• A menstrual cycle tracker offers phase-aware workout intensity recommendations; it avoids gender-based assumptions and treats cycle data explicitly.
• Health Connect integration syncs weight, nutrition, and exercise data with other Android health apps.
• Full data export (encrypted or unencrypted) allows users to back up history. Import supports moving devices without losing legacy records.

Those features are often the difference between an app that’s "nice" and one that becomes a daily habit.

Planned improvements: onboarding, BLE scales, and iOS considerations

Onboarding remains the weakest link. Musclog is more valuable as it accumulates data, but the initial user experience is still too close to “here’s everything, good luck.” Priorities include a guided onboarding flow that establishes goals, sets up a workout template, and logs a first meal in a streamlined sequence—getting users to value day-one data.

Hardware integrations like BLE smart scale support are straightforward technically but require hardware testing and QA. Adding automatic weight syncing reduces manual friction and improves daily logging fidelity.

Platform economics influence distribution choices. Android distribution is free with a one-time Google Play fee. iOS distribution would require Apple's annual developer fee, which creates a recurring cost for the maintainer. The developer signals a preference for a one-time purchase model if iOS requires monetization to offset platform costs.

Lessons for builders: practical takeaways from Musclog's rebuild

Musclog’s overhaul yields several practical lessons for product and engineering teams:

1. Design systems pay off. Define spacing, radii, and semantic colors early to prevent visual drift.
2. Use utility-first styling for consistent, refactorable layouts at scale.
3. Treat AI design tools as product clarifiers. The act of describing intent reveals UX problems that visuals alone will not.
4. Local-first architectures reduce operational costs and increase user privacy. For personal data-heavy apps, that can be a competitive advantage.
5. Use reactive local databases (like WatermelonDB) to reduce state-sync bugs and unify data logic across platforms.
6. Separate platform-specific renderers (charts, OCR) but keep a consistent public API for consuming components.
7. Combine multiple estimators (1RM formulas, TDEE signals) to reduce the fragility of single-model reliance.
8. Enforce strict schemas for LLM outputs to make AI features reliable.
9. Leverage public datasets (USDA, Open Food Facts) before paying for provider licenses; open data is often sufficient and more transparent.
10. Centralize encryption and security primitives in service layers so contributors don’t accidentally leak sensitive fields.

Those guidelines reflect a core theme: design and architecture choices should align with product intent. Musclog's rebuild shows that when those align, the product becomes simpler to use, simpler to maintain, and more trustworthy.

Where to try it and how to contribute

Musclog is available on Google Play and the code is hosted on GitHub. The app’s local-first, open-source approach invites inspection and contributions while keeping user data private by default. For developers, the repository offers examples of cross-platform patterns, WatermelonDB usage, encryption strategies, and strict schema enforcement for LLM interactions.

Download: https://play.google.com/store/apps/details?id=com.werules.logger Repository: https://github.com/blopa/musclog-app

Musclog's mantra—Lift, Log, Repeat—reflects the product’s simplest promise: make the small act of logging a workout or meal fast enough that it becomes habit, and ensure the data remains useful and private.

FAQ

Q: Is Musclog free? A: Yes—on Android the app is free on Google Play today. The developer intends to keep Android free for now. If future distribution costs force a change, the stated preference is for a one-time purchase rather than a subscription.

Q: Where is my data stored, and who can access it? A: All user data is stored locally on the device using WatermelonDB backed by SQLite on mobile and LokiJS on web. Sensitive fields (weight, body fat, nutrition logs) are AES-encrypted before storage. Nothing leaves the device unless the user explicitly initiates an export or uses AI features that call external models.

Q: How do AI features affect my privacy or cost? A: AI calls use the user’s own OpenAI or Google Gemini API key when configured. That means the user bears any model usage charges directly. The app does not proxy AI calls through a developer-owned server. Prompts and custom instructions are stored locally.

Q: How accurate is photo-based meal estimation? A: Photo estimation provides ballpark values, not scale-level precision. It is intended as a fast way to log meals when weighing or scanning is impractical. The app presents AI estimates for user confirmation before logging.

Q: What food databases does Musclog use? A: Musclog queries the USDA FoodData Central and Open Food Facts in parallel, merging results into a unified list. That covers a wide range of raw ingredients and branded products globally.

Q: Can Musclog work offline? A: Yes. The app is designed to be local-first and works in airplane mode for core logging and most features. Some features (remote food lookups, AI calls) require connectivity.

Q: Is my data encrypted and exportable? A: Yes. Sensitive data is AES-encrypted in the database by default. The app supports full exports as encrypted or unencrypted JSON for backups and device migration. Import allows restoring history on a new device.

Q: How are charts and platform differences handled? A: Charts use Victory Native/Skia on mobile and Victory with SVG for web. Components have platform-specific files (e.g., LineChart.tsx and LineChart.web.tsx) so the consuming code uses a consistent API while the runtimes use the best available rendering backend.

Q: How does Musclog estimate training volume? A: Musclog estimates 1RM per set using multiple established formulas, averages them, and accounts for optional RIR (Reps in Reserve). This produces a more robust volume metric than raw weight×reps and reduces dependence on any single 1RM formula.

Q: What is the weekly check-in and how is TDEE estimated? A: Weekly check-ins compute 7-day rolling averages for weight, calories, and activity, producing a status indicating whether you’re on track. TDEE is inferred empirically by observing your logged calorie intake and actual weight change over time rather than relying solely on formulaic BMR multipliers.

Q: Is the app open source and what is the license? A: The source is available on GitHub under the Attribution-NonCommercial-NoDerivatives 4.0 International license. This allows inspection and personal use but restricts commercial redistribution and derivative works without permission.

Q: Will Musclog be on iOS? A: There are user requests for iOS. The developer has noted Apple’s annual developer fee and distribution economics as factors that could push an iOS release toward a one-time paid model. No definite timeline has been announced.

Q: How can I contribute or suggest features? A: Contributions are welcome through the GitHub repository. Filing issues, opening pull requests, and suggesting improvements to onboarding or hardware integrations (e.g., BLE scales) are practical ways to contribute.

Q: What are the main lessons for builders from Musclog’s rebuild? A: Prioritize a design system and consistent styling early, choose a local-first data model for privacy-critical apps, centralize encryption, enforce strict output schemas for LLM integrations, and prefer public datasets before paying for proprietary feeds.

If you want to test the app’s recalculated TDEE, experiment with the weekly check-in after seven consistent days of logging; the app will use the observed intake and weight change to produce an empirically-driven maintenance estimate. If you want to inspect the encryption helpers, look in the service layer where all read/write operations route through the same utilities—security is implemented centrally, not sprinkled across the codebase.

Lift, log, and iterate: Musclog’s rebuild shows that thoughtful design and disciplined architecture can turn a functional hobby project into a reliable tool that respects user privacy and reduces friction for daily use.