Xandrov StudioAtlas of shipped systems
← The territory/ I. AI-Native Products/ № 04 — Fasting Tracker
Dossier № 04 / 19 — AI-Native Products — Product R&D · Web + Desktop

Fasting Tracker

One codebase, two surfaces, your own data doing the talking.

File
№ 04 / 19
Territory
AI-Native Products
Classification
Product R&D · Web + Desktop
Status
Live in production
§ 01 Context

Health-tracking applications fragment across form factors. They run in browser tabs—convenient but transient, abandoned between sessions—or as native applications where platform-specific maintenance is expensive and evolution is slow. The constraint isn't feature set. It's accessibility: users work across devices and contexts throughout the day. A tool confined to one surface misses them. This system targets portability: one codebase, two surfaces. The web version runs in the browser; the desktop version wraps the same application via Electron. No forking—same logic, same data, different entry points.

§ 02 The problem

Health tracking has a distribution problem. Apps either live in browser tabs—convenient but transient, easy to forget—or ship as native applications where platform-specific maintenance is expensive and updates lag. The real constraint isn't feature count; it's accessibility across where users actually work. Generic wellness advice compounds the problem. Insights that don't ground in a user's actual history feel hollow. The system needed to reject templated guidance and instead comment on what the user had logged.

§ 03 The approach

The application is built on Next.js with the App Router and TypeScript. Supabase handles authentication and stores all data in Postgres—the single source of truth for logged metrics. On the front end, Recharts renders trend visualizations. For insights, the system sends the user's complete fasting and weight history to Gemini; the model comments on patterns in the logged data rather than generating generic wellness templates.

Distribution happens two ways. A standard web deployment serves browser access. An Electron wrapper packages the same Next.js application as a desktop build. The wrapper doesn't fork the code—it loads the web app in a window and adds native desktop capabilities, keeping both versions in sync without duplication.

One codebase shipping as web and desktop. Insights read your history, not templates.

§ 04 Decisions that mattered
D1
One codebase, two surfaces
The desktop build wraps the Next.js app via Electron rather than forking logic. Shared code keeps both versions in sync and eliminates maintenance overhead.
D2
Insights ground in user data
Gemini receives the complete fasting and weight history. It comments on patterns in the logs, not generic wellness templates.
D3
Postgres as single source
All metrics route through Supabase's backend. Web and desktop clients sync against the same database—no platform-specific stores.
D4
Next.js for shared logic
App Router and TypeScript let the same code run in browser and Electron window without duplication or platform-specific branches.
§ 05 Where it stands

The system runs in production. Both web and desktop builds are live. Users log fasts, weight, and measurements; Recharts renders trends over time. The AI component works: Gemini reads the complete history and surfaces genuine insights grounded in logged data rather than offering generic commentary. The architecture—single codebase, two surfaces—has proven viable for shipping and maintaining both platforms.

Next.jsSupabaseRechartsElectronGemini
§ 06 — Sanitization record

User counts, revenue, usage patterns, and performance analytics remain undisclosed. The system runs in production at Xandrov Labs; the studio publishes architecture and design decisions but withholds detailed internal metrics, platform-specific benchmarks, and proprietary performance data.

Have a system like this worth building?

Fixed scope, quoted after one working session, first output inside two weeks. Read by a person within one working day.