StreakFocus: Three Tasks a Day

Key Facts

Role

Designer + developer, solo

Scope

iOS product, 0 to 1

Craft

Three-task constraint model

Outcome

Live, App Store

• The product is built around a hard constraint: exactly three tasks per day. Not configurable. The limit is enforced in both UI and state logic.
• A 3 AM day boundary prevents accidental streak breaks around midnight and protects consistency across time edges.
• Streak validation, milestone detection, and persistence checks are structural, not decorative.
• With Reduce Motion on, card transitions are instant and celebrations keep only fades.
• All state persists locally with dayKey validation to prevent drift and corruption.

Architecture & Interaction

Interaction Model

The app is structured around a single constraint: three tasks per day, no exceptions. A task is either done or not done. The day resets at 3 AM rather than midnight. That boundary exists because midnight arrives quickly and an arbitrary cutoff creates an unnecessary failure state for users, particularly those with ADHD, who are still working through their list. The later reset matches how people actually work rather than how calendars are structured.

Technical Implementation

Process

The constraint came first. Before any visual decisions were made, the three-task limit and the day boundary reset were defined as non-negotiable product rules. The design system was built around those constraints, not the other way around. Every component decision (the streak display, the task states, the reset behavior) was validated against the core rule before implementation began.

Front-loading system decisions reduced rework and kept the product cohesive.

I replaced a timer-based reminder with a state-based reminder, so the app reliably prompts you to refresh tasks even if you open it later in the day.

Impact

I built StreakFocus to test one premise: that a hard constraint on daily tasks would reduce friction rather than create it.

The premise held, and the hardest test of it was me.

Beta feedback tested that boundary. I chose to preserve the limit rather than make the product more permissive. Then twice I wanted a fourth task myself. Both times adding it would have diluted the point, and I could see exactly where it led: one more to do, then one more, then the list I built this to get out from under. The limit works because it does not negotiate, and I am the one most likely to try.

• Before submission, "wins" was renamed to "tasks" across all UI surfaces, notifications, and marketing copy. The original language implied celebration before completion.
• Streak mechanics reward showing up. Completing all three tasks counts the same whether they took twenty minutes or eight hours.
• The app shows a single task at a time. There is nothing else to choose.
• All data lives on-device. No account, no server, no sync. The streak belongs to the user.

The product shows that when constraints live in the architecture rather than in guidelines, discipline becomes a system property instead of a personal one.

Reflection

The hardest call was holding the three-task limit when testers pushed at the edges. Allowing exceptions would have made the product more flexible, but less honest about what the product was for.

Defining the constraint before designing the UI turned out to be the right sequence. It meant the state logic, milestone validation, and reset behavior all had to serve the same rule. The product stayed coherent because every system decision had to support that constraint.