Tare is a mobile habit reflection app that saves original check-ins, proposes structured fields for user review, and uses recorded history for progress views and insight paths.
Tare is a mobile habit reflection app for habits to build or avoid. Identity-oriented onboarding leads into written or transcribed check-ins, a diary, recent momentum, and history-based insight paths.
The app saves the original reflection before model extraction. Proposed completion and context fields are shown for review before the structured check-in is updated, keeping the person's words separate from the model's interpretation.
A completion mark alone cannot record the circumstances around a habit. A free-form reflection can, but it needs reviewable structure before the app can use it for progress and later observations.
Tare saves the reflection first, proposes structured fields second, and leaves the completion result open to the user's correction.
The flow gives people room to describe the day while retaining consistent check-in fields for the diary, recent momentum, and later insights.
As Founder & Lead Developer at DivWeavers, I built Tare across the React Native app and Supabase backend, including the anonymous first-run flow, habit and check-in screens, structured AI extraction, history and insight views, data rules, scheduled analysis, notification paths, Free/Pro integration, and mobile build setup.
One reflection is submitted at a time. Model output is a proposal rather than the authoritative user record, and extraction can fail after the original entry is saved.
One written or transcribed reflection becomes a structured check-in only after the person reviews the proposed fields.
Type freely or speak an entry and review its transcription in the same editable field.
Save the user's words before requesting analysis so they remain available if extraction fails.
Propose schema-checked completion and context fields; a successful result is not guaranteed.
Review the proposal and correct the completion value before finalizing.
Update the saved check-in after review; the model does not write the final record directly.
Use saved check-ins for diary history, recent momentum, and later insight paths.
This is the implemented architecture, not proof that each external integration is operating in production.
Identity-oriented onboarding, habit setup, check-in review, diary, and insight views.
Anonymous first-run sessions, habit and check-in records, row-level security, and tier rules.
Structured extraction, voice transcription, summaries, and external integration paths.
Report and notification paths based on stored history and habit timing.
Free-form check-ins vary, but progress views need consistent fields.
A model interpretation should not silently replace what the person actually wrote.
Save the original entry, request schema-checked extraction, and show the proposed fields for review.
Review adds a step and extraction may fail.
The original diary entry remains available even when structured analysis fails.
Build and break habits give the same completion field different meanings.
The app also needs an enforceable active-habit limit across Free and Pro tiers.
Treat completion as doing a build action or avoiding a break action, and enforce active-habit limits in PostgreSQL.
The onboarding UI can stage more habits than the current Free database rule permits.
The database remains the enforcement point; the onboarding inconsistency still needs product work.
A single check-in cannot establish a recurring context pattern.
Reports, correlations, and nudges need saved history and configured backend paths.
Derive rolling momentum from completed days and provide conditional paths for context observations, weekly reflections, friction reports, and cross-habit correlations.
Correlations and rule-based nudge scores do not prove causation, prediction accuracy, or behavior change.
The implemented views describe recorded patterns when enough history is available.
Write raw text before model extraction and make structured fields a reviewable proposal.
The user's words should survive an extraction failure or an incorrect interpretation.
Let the model response become the final check-in immediately.
The user reviews completion before the structured update.
The diary retains the original entry and the app can offer retry or Finish Later.
Calculate recent completed-day momentum from saved check-ins.
Progress views should use recorded completion state rather than generated narrative.
Use model-generated summaries as the progress measure.
Momentum describes recent history without explaining its cause.
The measure remains inspectable alongside diary entries and conditional insight reports.
The Expo app handles onboarding and review. Supabase Auth and PostgreSQL with row-level security hold profiles, habits, and check-ins. Edge Functions coordinate extraction, transcription, summaries, and external integrations; scheduled PostgreSQL work supports reports and notification paths.
The app includes a Free/Pro entitlement model. RevenueCat and Expo notifications are part of the integration architecture; their production operation is not established by repository code alone.
Tare writes the user's words before requesting model extraction. If analysis fails, the original entry remains and the UI offers retry or Finish Later; a structured result is not guaranteed. Typed output validation, row-level security, database habit limits, and report uniqueness support the implemented flow.
Tare has iOS and Android app architecture. This case study describes implemented product paths without claiming public store availability or verified external service delivery.
Saved check-ins support a diary and rolling momentum. Context observations, weekly reflections, friction reports, and cross-habit correlations are implemented paths that depend on sufficient history, tier, and configured services; they do not establish causes or outcomes.
Tare demonstrates product engineering across a mobile interface, durable records, reviewable AI extraction, scheduled backend work, notification paths, and subscription rules. The check-in remains a user-reviewed record rather than a model response alone.
Saving the original entry and reviewing proposed fields allows flexible input without treating an AI interpretation as unquestioned truth. Later views can draw from that saved history without becoming a separate chat memory.
Share the product problem, the current system, and where delivery is stuck.