DayFlow. A spending tracker built around one question.

01 / The problemThe night-before-bed check that doesn't have a tool

I've used most of the major personal-finance apps. They are all good at the same thing and they all have the same blind spot. The thing they're good at is the post-mortem: at the end of the month, here's where your money went, broken down by category, with a chart. The blind spot is the in-the-moment decision: at 9:47 p.m. on a Wednesday, am I in or out of bounds for today, and should I order the second beer.

The post-mortem use case isn't worthless. It's just the wrong tool for the job that actually changes spending behavior. The job that actually changes behavior is the daily checkpoint, because the unit of self-correction is a day, not a month. By the time the monthly chart arrives, the behavior it reports on is already locked in.

The other thing that kills existing tools for this use case is the setup ritual. Bank linking is friction. Category configuration is friction. Multi-account reconciliation is friction. The version of the product that delivers value tonight is the version that lets you log a $42 charge in two taps and see the day-over-day shape of the week without any of the above.

02 / Scope disciplineWhat's in v1, what's out, what's later

The biggest decision on this build is what I'm not doing in v1. The temptation to build the kitchen-sink personal-finance product is real. The version of this that ships in eight weeks is small on purpose:

03 / WireframeThe one screen that has to work

The product is approximately one screen. If that screen is right, the product is right. If that screen is wrong, no amount of secondary navigation will save it. Sketch:

The hierarchy is intentional: the biggest number is "today's spend vs today's target." The second biggest is "week so far vs week target." Everything else is supporting evidence for those two. The add button is the only persistent action because adding charges is the only thing the user has to do for the product to work.

04 / Data modelThree tables, one job

The schema is small on purpose. Anything more elaborate is paying for features that aren't in v1.

Three notes on the model. One, all amounts are integer cents to dodge floating-point rounding. Two, occurred_on is computed from occurred_at and the user's timezone, because "today" is a per-user concept and the database needs to know what user A's "today" is, not the server's UTC today. Three, the tag field is free text intentionally. Adding a category table is a half-day of work and a lifetime of category-bikeshed support requests; v1 deliberately skips it.

05 / Auth and securityMagic link plus row-level security

Auth is Supabase magic link. No passwords, no OAuth setup, no third-party identity to maintain. The user enters an email, gets a link, taps it, is in. For a single-user-per-account product where the data isn't catastrophically sensitive but is real personal info, magic link is the right balance of friction and security.

Row-level security on Postgres is the load-bearing piece. Every row in charges and target_overrides is queryable only by the user that owns it. The policy is mechanical:

-- charges table: user can only see and modify their own rows
create policy "users see own charges"
  on charges for select
  using (auth.uid() = user_id);

create policy "users insert own charges"
  on charges for insert
  with check (auth.uid() = user_id);

The reason this is worth highlighting is that every Supabase project has the option to skip RLS, and a non-trivial number of public Supabase projects ship with it disabled. v1 will not.

06 / Build status, honestlyWhat's done and what's next

Where the codebase actually is, as of this writing:

07 / Caveats I want statedWhere this could be wrong