Should I Buy This? — A Spending Decision Tool Built with AI

A full build case study — the friction that started it, the constraint that shaped it, what was built, what was deliberately left out, and why adding friction was the whole point.

The friction that started it

Impulse purchases don't happen because people are careless. They happen because there is no pause. You see something, you find a reason to justify it, and you buy it — the decision happens so fast it barely registers as a decision at all.

Most financial tools try to solve this by tracking everything after the fact: budgets, categories, dashboards, spending history. But by the time those tools are useful, the money is already gone. They optimise behavior in hindsight. The problem happens in the moment, and nothing was addressing that.

The question was simple: what if the tool intervened before the purchase, not after it?

The constraint (and why it was the point)

Before writing a single prompt, one constraint was set: this could not become another budgeting app. No accounts, no tracking, no dashboards, no long-term data. It had to work in one moment — right before spending happens.

It also had to run locally with no setup required and feel fast enough that using it takes less time than skipping it. That last part matters more than it sounds. If a tool feels like effort, people bypass it — and the impulse purchase happens anyway. The tool only works if it gets used, which means it cannot slow down the person using it.

Removing all persistent state — no history, no memory, no account — also made it private by design. Nothing is stored, nothing is transmitted. That is not a limitation. It is what makes it trustworthy enough to open at all.

What was built (and how)

The tool was built over a weekend using AI, with a deliberate focus on design quality from the start. Previous builds on this site had functional but generic interfaces — this one used Google Stitch to push the visual design further, aiming for something that felt considered and worth opening, not just usable.

The core logic is entirely rule-based. It asks four questions: what you are buying, how much it costs, how often you will use it, and why you want it. It then evaluates need, urgency, budget fit, and financial pressure — and returns a clear verdict with a short explanation. No machine learning required. The rules are predictable, the output is fast, and the judgment is consistent.

What stayed in

  • Four structured questions covering need, cost, frequency, and intent
  • A clear verdict — buy, wait, or skip — with a brief explanation
  • Runs entirely in the browser with no setup or account
  • Designed to feel worth using, not just functional
  • No data stored, no data transmitted, no history kept

What was left out

  • User accounts — nothing to log in to, nothing to manage
  • Spending history — tracking over time was out of scope by design
  • Budgets and categories — adds complexity without changing the core behavior
  • Long-term analytics — the goal is the single decision, not the pattern
  • Integrations — nothing to connect, nothing to break

Every feature that was cut would have made the tool slower to open and easier to ignore. The constraint was not a shortcut — it was the product decision.

The role AI played

AI handled the construction work. The judgment about what to build, what to cut, and where to draw the scope boundary was still entirely human.

The prompt was specific: a single-screen spending decision tool, no backend, no persistence, rule-based logic, a verdict with explanation, and a design that feels considered rather than generic. That specificity is what made the AI output useful. A vague prompt would have produced a full budgeting application with dashboards, categories, and a login screen — exactly what this build was trying to avoid.

Google Stitch was used to develop the visual design — specifically to move beyond the default component aesthetics and produce an interface that matched the tone of the tool: direct, confident, and fast.

For more on keeping scope controlled when working with AI tools, see how to clarify an app idea before building.

What the tool actually does

The tool does one thing: it interrupts the impulse cycle at the moment a purchase is being considered. It turns "I want this, so I'll buy it" into "I want this — let me check whether that actually makes sense right now."

That change is small. But it compounds. A split-second decision becomes a ten-second check. The ten-second check catches the purchases that would have been regretted. And the ones that pass the check get bought with confidence rather than guilt.

The tool does not know your income, does not understand your full financial situation, and does not track patterns over time. It makes a judgment based on limited input. That is enough — because the goal is not perfect financial advice. It is a second look before spending. Nothing more.

What this build demonstrates

This build makes three things clear. First, not everything useful requires AI in the decision logic. The core of this tool is rule-based — price sensitivity, usage frequency, stated intent. No model, no inference. That makes it fast, predictable, and free to run.

Second, small tools can change behavior directly. You do not need dashboards, analytics, or automation to be useful. You need the right interruption at the right moment — and this build shows that a focused tool can deliver that without complexity.

Third, friction is not always the enemy. Most software tries to remove as much friction as possible. This tool adds friction deliberately, at the one point where it actually helps. That is a different way of thinking about what a tool is for.

The constraint — no tracking, no accounts, no system — is not what limits this tool. It is what makes it work. The other real builds on this site follow the same logic. See all real builds.

Key lesson: adding deliberate friction at the right moment — right before a purchase — changes behavior more than any dashboard or tracking system.