Money Reality OS: Building a Local Budgeting App That Actually Fits Daily Life

Three tools that came first

Money Reality OS did not start as a big finance app. It started as three smaller ones.

The first was the Reality Checker — a spending decision tool that asks a few structured questions and tells you whether a purchase makes sense right now. One input, one verdict. No data saved, no history, no accounts. Built to create a moment of friction before the tap.

The second was the Spending Reality Check — a local-first tracker that surfaces spending patterns without requiring bank connections or subscriptions. Everything in the browser, data in localStorage, nothing shared anywhere. Built to show behaviour rather than just totals.

The third was the Subscription Leak Finder — a tool for adding up what subscriptions actually cost across a month and a year, flagging the ones worth reviewing first. Built because subscription costs are invisible until you force yourself to list them.

Each of those three tools solved one thing. Each confirmed that local-first worked, that people did not need accounts to find the tools useful, and that the constraint of doing less was the right approach.

But after building them separately, it became obvious they were solving parts of the same problem. The Reality Checker was the decision layer. The Spending Reality Check was the tracking layer. The Subscription Leak Finder was the recurring cost layer. They belonged together — not merged into one screen, but available from one place, sharing the same data and the same design language.

That is where Money Reality OS came from. Not from a product brief. From three tools that kept pointing at each other.

Where the build started

Money Reality OS had solid bones. The first version covered the full personal finance loop: daily expenses, income tracking, subscription management, a spending decision tool, a monthly review, and full export and import. All local. No accounts. Nothing sent anywhere.

That part was done. What wasn't done was making it feel like something worth opening on a Thursday morning when you've just bought a coffee and want to log it quickly before you forget.

The original build used vanilla JavaScript and plain CSS. No React, no build toolchain beyond what was needed. That was a deliberate choice and it turned out to matter a lot once the design work started.

The design direction came from a separate prototype folder: the Nocturnal Clarity palette, defined in a DESIGN.md file. Deep navy surfaces, a sky-blue accent, slate-coloured text, soft borders, and two specific typefaces: EB Garamond for headings and Hanken Grotesk for body and UI. The goal was something calm and readable — not a finance dashboard, not a banking portal.

What went well

The app having strong local-first functionality from the start made a real difference. There was nothing to unpick or replace at the data layer. The focus stayed entirely on how it looked and how it felt to open and use.

The Nocturnal Clarity palette translated directly from the design file. The navy surfaces, the sky-blue accent on interactive elements, the soft border treatment on cards — they all held up. The palette had been thought through properly. It wasn't just a colour mood board; it had a logic to it.

The typography choice turned out to be the right one. EB Garamond for headings gives the app a slightly considered, unhurried quality that most finance tools don't have. Hanken Grotesk for UI text is clean without being clinical. Together they make the interface feel like it was built for reflection, not performance reporting.

Making Daily Expenses the default view was the single most important structural decision of the week. Expense entry is where most of the daily action is. It is the thing you open the app to do. Opening onto the dashboard first was solving for the review use case when the entry use case is actually more frequent. Switching the default fixed that immediately.

The dashboard concepts from the prototype — summary cards, category rows, review items with calm copy — translated well into the vanilla JS structure. The architecture didn't fight the design. That matters more than it sounds.

What didn't work

The design prototype was built in React with Babel. The actual app is vanilla JS. That gap meant the prototype couldn't be transferred directly. Every component had to be re-expressed in plain HTML and CSS. It was not difficult, but it was a manual process that couldn't be shortcut.

The first pass at the dark theme was too heavy. Deep navy everywhere, low contrast in the wrong places, and a general heaviness that made the interface feel like a late-night data terminal. Useful for one kind of mood. Not useful for something you open first thing in the morning or in the middle of the workday.

Opening onto the dashboard was the other obvious problem. A dashboard is where you go to understand patterns. It is not where you go to log a £3.50 coffee. Starting there every session created friction before the user had done anything.

Some of the prototype styling was more editorial than practical. It looked good in static screenshots but didn't hold up in repeated daily use — particularly in forms, where the spacing and visual weight needed to be tighter and more functional.

There was also a conflict in the design direction documents. One file described a calmer light mode approach, while DESIGN.md explicitly defined Nocturnal Clarity as a dark navy system. That kind of mixed signal costs time. The DESIGN.md file was the authority and everything was built from that. The other document got ignored.

What had to change

The default landing page was changed from Dashboard to Daily Expenses. That was the clearest single fix.

The navigation order was updated so Daily Expenses appears first. Navigation order signals priority. If expense entry is the primary action, it should be first — not buried after a dashboard that most sessions don't need.

The expense page was reworked into a proper primary workspace. It now has a three-card summary row at the top: today's total, this month's total, and a regret indicator for flagged purchases. The cards give you context without sending you somewhere else. You can see where you are and then get on with adding the next entry.

The colour system was rebuilt from the DESIGN.md values. Deep navy for surfaces and backgrounds. Sky blue for the active accent and interactive elements. Slate for secondary text. Soft, slightly muted borders on cards and containers. The first heavy pass was stripped back and reapplied with more restraint.

Fonts were swapped to match the design file. EB Garamond on headings and section titles. Hanken Grotesk on body text, labels, form elements, and navigation. The previous font stack was generic and gave the interface no character.

Cards, inputs, buttons, navigation items, headings, tags, and all dashboard sections were restyled to match. The CSS was rebuilt section by section rather than patched on top of what was there. Patching would have left conflicts. Starting from the design file and working down was slower but resulted in a cleaner output.

The dist folder was rebuilt once all the changes were in. That step is easy to forget and it has bitten this project before.

The thing the design work actually taught me

A working app and a daily-use app are not the same thing. The first version of Money Reality OS worked. It tracked the right things, stored data locally, handled import and export. All of that was correct. But correct and usable are not the same measure.

The design system forced a different question. Not "does this function?" but "would you actually open this in the morning?" That shift changes what you build and in what order. It changes which view you put first. It changes how heavy the typography feels on a tired afternoon. It changes whether the first thing you see is useful information or a chart that takes cognitive work to read.

Most personal finance tools are built for the power user reviewing a month's data on a Sunday afternoon. Money Reality OS is being built for the Tuesday morning when you just want to log yesterday's petrol and see if you're still on track. That's a different product. Getting the design right is most of what makes that distinction real.

What the app does right now

The full feature set that was there before is still there:

• Daily expense entry with categories and optional regret flagging
• Income tracking across different sources
• Subscription manager with monthly and yearly totals
• Spending decision tool for individual purchases
• Monthly review with summary and category breakdown
• Full export and import via JSON

None of that changed. What changed is that it now opens on the right page, uses a coherent visual system, and feels considered rather than assembled.

Everything runs in the browser. Nothing is sent anywhere. No account needed. No subscription. The data is yours and it stays on your machine.

Stack and setup

Deliberately minimal.

• Vanilla JavaScript
• Plain CSS with the Nocturnal Clarity design system
• EB Garamond & Hanken Grotesk from Google Fonts
• Browser localStorage for all data
• No frameworks, no backend, no build toolchain beyond a dist folder

The simplicity of the stack was one of the things that made the design overhaul tractable. There were no component libraries to override, no CSS-in-JS specificity battles, and no framework opinions about how the layout should be structured. The design file was the source of truth and the CSS reflected it directly.

What comes next

The design is in a state worth keeping now. The next question is whether the daily workflow actually holds up over real use rather than a test session.

A few things are on the list for the next pass:

• The regret flagging needs cleaner UX — the current version works but it is slightly clumsy to use inline
• The monthly review could surface a sharper single insight rather than a full breakdown
• The subscription page needs the same card treatment the expense page got this week

None of those will change the core. They are refinements for daily use rather than features. That is the right direction for this stage of the build.