Spending Reality Check: How I Built a Private Spending Tracker with AI

The Friction That Started It

The problem was not that I didn't know how to track spending. It was that every tool built to help with that made the problem worse.

Most budgeting apps require you to connect a bank account, create an account, and work through an onboarding flow before you see a single useful number. By the time you've done all of that, the friction has already won. And the apps that skip the setup usually replace it with complexity — dashboards full of categories, charts, and projections that look analytical but answer nothing useful.

The one question I actually wanted answered was simple: is my spending drifting higher, and where? No app I tried answered that clearly. So I built one that did.

The Constraint (And Why It Was the Point)

Before writing a single prompt, I set one hard constraint: no backend, no accounts, no data leaving the device.

This was not a technical limitation — it was a deliberate design decision. Most people who abandon budgeting tools do so because of trust and friction, not features. They do not want their financial data stored on someone else's server. They do not want to manage a subscription to see their own spending. And they definitely do not want to re-authenticate every time they open the app.

Removing the backend removed all of those failure points at once. Everything would run in the browser, use local storage, and require zero setup. That constraint defined everything else about the build.

What Was Built (And How)

The entire tool was built in a single session using AI. The prompt was precise: a static HTML/CSS/JS spending tracker that stores data in localStorage, shows weekly totals, highlights drift between weeks, and requires no setup or login.

The AI produced a working first version quickly. The iteration was not about adding features — it was about removing them. The first draft included category breakdowns, monthly summaries, and export functionality. All of it was cut.

What stayed in

• Manual purchase entry — amount, description, date
• Weekly totals with drift comparison (this week vs. last week vs. the week before)
• Subscription detection — recurring amounts flagged automatically
• All data stored locally in the browser, never transmitted
• No login, no setup, no onboarding

What was cut

• Category tagging — adds friction, rarely changes behavior
• Monthly summaries — too long a feedback loop to be actionable
• Charts and visualizations — numbers are clearer than charts for this use case
• Export — useful in theory, not worth the added surface area
• Budget limits — people don't need limits, they need visibility first

Each cut made the tool faster to use and harder to abandon. Every feature removed was a decision point eliminated from the daily habit.

The Role AI Played

AI did the construction work. The judgment about what to build was still entirely human.

The session started with a clear spec: what the tool does, what it does not do, and why. The AI produced a working base quickly. Iteration focused on refining the weekly drift display and simplifying the entry form — not on expanding scope.

The AI was useful precisely because the prompt was constrained. A vague prompt produces a bloated result. A specific prompt produces something you can actually use. This build is a direct demonstration of that principle.

For more on that tradeoff, see how to clarify an app idea before building.

What the Tool Actually Does

The Spending Reality Check does one thing well: it shows you whether your spending is drifting, and in what direction.

You log purchases as you make them — or at the end of the day. The tool shows you this week's total next to last week's and the week before. That comparison is the entire feedback loop. If spending is creeping up, you see it within days, not months. You can identify the week it changed and usually remember exactly why.

No categories. No charts. No subscription. Open it, log something, see where you stand. That is the full experience — and it is more useful than most tools that do ten times as much.

What This Build Demonstrates

The Spending Reality Check is a proof of concept for a specific way of building: start with friction, apply a hard constraint, cut everything that doesn't serve the core use case, and ship the smallest useful version.

The constraint — no backend, no accounts — was not a workaround. It was the most important product decision in the build. It eliminated the primary reasons people stop using spending tools. The simplicity is not a lack of ambition. It is the result of deliberate restraint.

That approach works in any domain. The tool itself is about spending. The lesson applies to almost anything worth building.

See how the same principles apply across all real builds on this site, or read more about choosing the right AI tool for your own build.