SpendShield

SpendShield helps you pause before spending, see how purchases affect your goals, and build healthier money habits with real-time budget insights and voluntary gambling safeguards.

Comment

Inspiration

A budget can explain where money went, but the difficult moment often comes before a purchase. A price tag shows dollars; it does not show what that decision means for a personal goal.

We wanted to make that tradeoff visible while there is still time to choose. SpendShield brings together spending awareness, practical alternatives and voluntary safeguards, without making shame or competitive rewards part of the experience.

What it does

SpendShield turns a possible purchase into a concrete question: How much of my remaining budget does this use, and how might it change my savings timeline?

Users can plan around weekly, biweekly, twice-monthly or monthly pay, record transactions, import CSV files and track a savings goal. Purchase Shield lets them compare prices, wait before deciding, skip a purchase or record a verified cheaper alternative.

The SpendShield Live Chrome extension brings those choices onto relevant shopping pages. Gambling Guard adds a user-selected weekly limit, a voluntary 24-hour pause and an optional page cover on detected gambling sites. Users can record money they intend to put toward their goal instead.

The dashboard distinguishes protected intentions from confirmed savings. Nothing transfers automatically: users confirm savings only after setting money aside themselves. Optional Gemini features interpret purchase descriptions, screenshots and relevant page context, while the financial calculations remain deterministic.

Daily-review challenges, 20 achievements and unlockable color themes recognize reflection and planning. They offer no random prizes, financial rewards or penalties for missing a day.

How we built it

We built the interface with React, TypeScript and Vite, backed by a Python FastAPI service and SQLite. A Chrome Manifest V3 extension connects relevant page interactions to the same budget, goal and decision records used by the main app.

Financial amounts are stored as integer cents, with Decimal arithmetic for ratios. The goal model uses the remaining amount and planned monthly contribution; for a positive contribution, the baseline is:

$$ D = \left\lceil \frac{30R}{M} \right\rceil $$

Here, R is the remaining goal amount and M is the monthly contribution. This is an illustrative scenario using a 30-day month, not a guaranteed completion date.

Gemini runs through the backend with an optional user setting. It helps interpret unstructured inputs; it does not decide the financial totals. Manual inputs and rule-based analysis keep the core experience useful when AI is unavailable.

We also packaged a portable Windows version and an isolated fictional demo profile so the complete browser-to-dashboard workflow can be demonstrated without personal financial data.

Challenges we ran into

A central challenge was keeping an intention separate from an outcome. Skipping a purchase does not prove that money reached a savings account. We addressed that with separate planned and confirmed amounts, explicit confirmation and undoable decisions.

Browser pages introduce another challenge: product names, totals and layouts vary. We combined bounded metadata and page-text extraction with price confirmation and optional AI interpretation, while keeping manual entry available.

We also needed safeguards that respected user choice. Shield Mode is voluntary and bypassable, while achievements reward reflection rather than spending or gambling. Cosmetic rewards never restrict access to financial tools or support resources.

Accomplishments that we're proud of

We connected the decision on a shopping page to its budget impact, goal scenario and dashboard record in one workflow. In the fictional demonstration, a $60 cheaper-option difference and a $30 redirected decision become $90 in protected intentions, with confirmed savings unchanged until the user acts.

We are also proud of the supporting details: pay-frequency planning, persistent purchase waits, correction tools, clear fallback states, and repeatable demos. Automated backend, interface and extension checks cover key workflows, including the distinction between planned and confirmed savings.

What we learned

We learned that useful financial software needs more than a persuasive explanation. It needs consistent arithmetic, visible assumptions and a clear distinction between what the user recorded and what the system can verify.

We also learned to give AI a bounded role: interpreting messy information while ordinary code handles amounts and state changes. Thoughtful defaults and honest limitations are as important to the experience as the number of features.

What's next for SpendShield

Our next priorities are usability testing, broader real-site extraction tests, and measuring whether users understand the tradeoffs and confirmation steps. We also want to deploy the prepared hosted architecture and add authenticated extension pairing for hosted accounts.

Bank integration is a possible future direction, with explicit consent and careful data handling. Today, SpendShield uses manual or CSV records, does not move money, and does not claim to treat gambling addiction. We want to improve its usefulness through evidence and user feedback before making stronger claims about outcomes.

Built With

Share this project:

Updates

Submission history