HabitTracker app PRD: ship a daily check-in MVP in a weekend
A working HabitTracker MVP doesn't need 20 features. It needs daily check-ins, a streak counter, and a weekly recap that brings users back. This PRD captures that shape and matches it to the AI builder that ships it fastest: Lovable, because the whole app is Supabase tables plus a tight CRUD UI. v0 would make it prettier; Cursor would give you more control; Lovable lands the working version on Saturday afternoon.
What this is
A HabitTracker app PRD spells out the data model, the daily flow, the streak math, and the weekly email job for a small habit-tracking web app. It targets a v1 that a solo developer can ship in 8 to 12 hours of focused work, deploy to a real URL, and onboard 10 to 20 testers within a week. The scope explicitly excludes social features, mobile apps, and monetization for v1; those compound complexity without adding user value at this stage.
Compared to alternatives
| Option | Best for | Trade-off |
|---|---|---|
| Lovable | CRUD + auth + Supabase in one shot; matches the data-heavy shape of HabitTracker | UI is functional rather than beautiful; expect to polish |
| v0 | Polished UI components; great if your users care about visual feel from day one | You'll wire Supabase by hand; adds a day |
| Bolt | Stack flexibility if you want Astro or SvelteKit instead of React | More choices to make up front; less opinionated on backend |
| Replit Agent | Good if you want everything (code, DB, deploy) in one tab forever | Lock-in is real; export later is more work than starting in GitHub |
| Cursor + Claude Code | Full hand-control of the codebase | Slowest to v1; best for v2 onward |
| No-code (Glide, Softr, Bubble) | Even faster v1 if you accept the platform's limits | No code export; harder to extend; per-row pricing scales badly |
A real example
Product Requirements Document — HabitTracker v1
TL;DR
A web app where users track up to 5 habits with daily check-ins, see streak counts, and get a Sunday morning email summarizing the prior week. Target audience: solo founders and indie developers who tried Streaks or Habitica and bounced because of the gamification overload. Success: 50 weekly active users within 30 days of launch.
Goals (business):
- 50 WAU within 30 days
- 25% week-2 retention
- $0 paid users (free in v1)
Goals (user):
- Set up first habit in under 90 seconds
- Daily check-in in under 10 seconds
- See current streak count without an extra click
Personas:
- Marcus, indie founder: tried 3 habit apps, none stuck. Wants minimal friction.
- Lila, grad student: uses paper bullet journal but wants the streak data to compound.
Functional requirements (P0):
- P0-1. Email + magic-link auth. Acceptance: user gets the magic-link email in under 30 seconds.
- P0-2. Create up to 5 habits. Acceptance: form validates name (3 to 30 chars) and saves to Supabase.
- P0-3. Daily check-in for each habit. Acceptance: tap or click toggles today's status; idempotent across reloads.
- P0-4. Streak counter shows current run + best run. Acceptance: streak math handles missed days correctly (resets on miss; counts consecutive days only).
- P0-5. Sunday morning email summary. Acceptance: delivered at 8am local time with per-habit week count and current streak.
Functional requirements (P1):
- P1-1. Pause a habit without deleting (for vacations).
- P1-2. Delete a habit with confirmation.
UX flow: 3 screens.
- Sign-in (email + magic link)
- Dashboard (habit list with today's check-ins + streaks)
- Settings (timezone, email opt-out)
Success metrics:
- 60% of new users complete day-1 check-in
- 30% open the Sunday email
- Streak math has zero off-by-one errors across 100 test sessions
Technical considerations:
- Stack: React + Supabase (Lovable defaults)
- Deploy: Vercel via Lovable export
- Email: Resend via Supabase Edge Function
- Timezone handling: store user's IANA tz; calculate "today" on the server
Lovable appendix — Supabase schema:
userstable is created by Supabase Authprofiles(id uuid → users.id, timezone text, weekly_email_opt_in bool)habits(id uuid, user_id uuid, name text, created_at timestamptz)check_ins(id uuid, habit_id uuid, user_id uuid, occurred_on date, unique (habit_id, occurred_on))- RLS: each user reads + writes only rows where user_id = auth.uid()
- Edge Function: weekly cron at 12:00 UTC, computes which users are at 8am local, sends Resend email
Out of scope (v1):
- Social features (no shared habits, no leaderboards)
- Mobile app (web-only, PWA-installable)
- Paid tier
- Habit categories or tags
- Reminders beyond the weekly email
How to use this
- Pick Lovable. This shape is exactly what Lovable was built for. Don't overthink the choice.
- Paste the Lovable appendix into the prompt first. Schema-first prompts get cleaner Lovable output than feature-first prompts.
- Ship the v1 without the P1 items. Pause-a-habit and delete-with-confirmation can land in week 2.
- Use Resend's free tier for v1. 100 emails/day is plenty for the first 50 users.
- Get 10 real testers in week 1. Personal network is enough. Treat their first-day-2 retention as the most important signal.
- Don't add features until 30% week-2 retention. Below that, the product isn't worth feature investment. Above that, the next feature is "habit categories" (a P2 from feedback).
FAQ
Why exclude social features?
Social features compound complexity (privacy, moderation, notifications) without proving the core hypothesis. The core hypothesis is "people want a low-friction daily check-in tool." Validate that first. Add social only after 30% week-2 retention shows the core loop works.
Should the streak break on a single missed day, or have a grace?
V1: hard break on miss. Grace periods are a feature with a strong opinion (it changes the psychology of the app), and they're easier to add in v2 if testers ask. Hard break is the conventional behavior most users expect.
Is daily email better than weekly?
Daily email is noisier; weekly is friendlier and the open rate is higher. For v1, weekly is correct. Daily can become a P2 opt-in for power users in v2.
How does this PRD adapt for a mobile-first version?
The same Supabase schema works. Swap React + Vercel for Expo + Supabase. Lovable doesn't generate React Native today; Bolt or Cursor would handle the mobile version better. The PRD content above is mostly portable; only the technical considerations change.
What's the cheapest path to running this for the first 100 users?
Supabase free tier covers 50K monthly active users on the database side. Resend free tier is 100 emails/day, enough for 100 weekly emails per cohort. Vercel free tier handles the web hosting. Total cost for first 100 users: $0/mo. The first bill arrives at ~500 paid users, which is a problem you'll be glad to have.