Case study

Winter Arc

Every October my feed fills with Winter Arc plans, and most of them quietly die by mid-month because nothing is at stake. Winter Arc is the opposite of a habit tracker: you sign your goals like a contract, they lock for 90 days, and your friends can see whether you showed up.

Next.jsTypeScriptSupabasePostgreSQLDrizzleOneSignal
Role
Solo: product, architecture, build
Timeline
One night, Oct 1, 2026
Idea to live
About 9 hours
Users
53 in the first 4 days
  • Idea to live in about 9 hours
  • 53 users in the first 4 days
  • Tiers shipped on day 3, from user feedback
  • Security issues fixed before launch

Why I built it

At 12:30 AM on October 1st, I saw a post on X from someone sharing their Winter Arc checklist: ship products, read books, get fit. My feed was full of the same thing. Everyone was "locking in," and from experience, most of those plans quietly die by mid-October.

Habit trackers already exist, but they share the same weakness: nothing is at stake. You can edit your goals, delete a bad week, and quit without anyone noticing. I wanted to build the opposite. You sign your goals like a contract, they lock for 90 days, and your friends can see whether you showed up.

The Winter Arc was starting that day, so if I was going to build it, it had to be that night.

How I built it

I skipped sleep and worked through the night. The first few hours went into thinking, not coding. I brainstormed eight concepts, from a minimal countdown to a "graveyard" of abandoned goals, and narrowed them down by asking one question: what would actually make someone come back on day 14? The answer was other people. So I built the product around friend duels on one or two shared habits, layered on a personal 90-day Arc.

Then I planned the features, data model, scoring rules and architecture before writing code. That exposed problems early, like friends in different time zones, partners who disappear mid-duel, and weekly goals that make rest days look like failures.

I built it with AI coding tools, which made a one-night build possible. My job was the product decisions, the architecture, the scoring rules, and reviewing everything that was generated. A big part of the night went into testing, debugging and a security review, which caught and fixed issues like an open redirect and public real-time channels before anyone signed up.

By 10 AM, about nine hours after seeing that post, Winter Arc was live.

What's inside

  • The contract: users write habits and goals, sign with a real signature, and the terms lock for 90 days. A sealed letter to their future self opens on day 91.
  • Duels: friends compete on shared habits, agree on stakes, and get weekly rounds, a joint streak, and live updates when a partner checks in.
  • Tiers and comeback stories: users climb tiers as they keep their promises, and unlock one of 90 curated, fact-checked stories each day about real people who refused to quit.

Engineering highlights

  • Time zones without lost days. Every check-in is stored by the user's local date, with a 10 AM grace window. A time-zone change only takes effect at the next local midnight, so travel never creates or deletes a day.
  • Idempotency everywhere. Check-ins are upserts on a unique (goal, date) key, so double taps can't double count. Notifications use idempotency keys, and one-time emails use an atomic "claim, then send" update for at-most-once delivery.
  • Deterministic scoring. The scoring engine is pure: no I/O, with the clock passed in. That makes streaks, weekly buckets, freezes and tier crossings fully unit-testable. Check-ins are indexed into hash maps for constant-time lookups.
  • Secure by default. Row-level security denies all direct database access, so every request goes through the server. Real-time duel channels are private and carry no personal data. Links that work without login use HMAC-signed tokens.
  • Rules enforced by the database. A partial unique index guarantees one active Arc per user. CHECK constraints and composite keys protect the data even if app code has a bug.
  • No paid infrastructure. Background jobs run on Supabase's pg_cron, with each step isolated so one failure doesn't block the rest.

How it's going

I launched at 10 AM on October 1st with a post on X. Four days later, 53 people are using Winter Arc.

Since launch, I've been shipping based on what users tell me. Tiers went live on day 3, and I'm continuously improving the UX based on constant feedback from users. I also use it myself, tracking DSA and system design in my own Arc, so I feel every rough edge firsthand.

What I learned

Thinking first made building fast. Even with only one night, spending the first hours on concepts, scoring rules and edge cases meant I wasn't redesigning halfway through.

AI writes code fast, but judgment is still the job. The security review found real issues in generated code, and AI-written stories needed fact-checking because they repeated popular myths. Speed came from the tools; quality came from reviewing what they produced.

Real users beat assumptions. Features I thought were finished looked different once people used them. Shipping early and listening has improved the product more than any amount of planning could have.