Inspiration
Regrets-A started with a simple question: "Why do we keep making purchases that we later regret, even when we know better?" A lot of "personal finance" tools try to answer this using bank transaction data, surveillance-style tracking, or opaque scoring. I wanted the opposite: a tool that respects autonomy and privacy while still being genuinely helpful. So I designed Regrets-A around one principle: If the user doesn't explicitly confirm it, the system does not assume it. That means the model learns only from what the user chooses to log: kept / returned / unused / regretted and a satisfaction rating.
What it does
Regrets-A helps you decide if a purchase is likely to turn into regret for you. You type in the basics of what you're about to buy (category, price, planned vs impulse, "need/want/deal", how long you've been considering it, time of day). It then gives you a simple Low/Medium/High regret risk score with a plain "here's why" breakdown and a few non-pushy suggestions (like waiting 24 hours, setting a return reminder, or sanity-checking the budget). After you buy something, you log what happened - kept, returned, unused, or regretted- and 1-5 satisfaction rating of what you purchased. That's the whole point: over time the score gets personalized based only on your own explicit outcomes, not your bank data or tracking.
How I built it
Architecture (simple + local) Regrets-A is a lightweight local web app: Flask UI: forms for "Check a purchase", "Save pending", "Log outcome", "History". SQLite storage: local file DB for purchases and outcomes. Interpretable scoring model: weighted signals + sigmoid -> score + band + explanations.
Scoring approach: I compute a small set of "risk signals" (normalized to roughly[0, 1]), weight them, then convert into a 0-100 score
At a high level: z= ∑ wi . Si (this formula isn't complete, because I can't find the right symbols, letters, numbers to use from the keyboard to demonstrate the exact formula).
Then map to a score using a sigmoid: score = 100 . o(z) = 100 . 1/1+e-z (also not a complete formula but a demonstration of the formula).
Finally, we bucket into Low / Medium / High and produce a "Why this score" breakdown table. This isn't trying to be a perfect predictor - it's designed to be explainable, consistent, and easy to reason about.
Challenges I ran into
- Dependency and environment instability on Windows: Early on, I used a UI stack that pulled in heavier scientific dependencies. On Windows, that led to issues like DLL import failures and package lock conflicts (especially with synced folders). This caused startup crashes and long debug loops.
I simplified the stack:
- Dropped heavy dependencies
- Migrated to Flask + pure Python logic
- Added scripts to rebuild and run reliably
2nd challenge... Making the model useful without being paternalistic: A regret score can easily become judgmental or controlling.
I intentionally framed output as:
- advice, not enforcement
- explanations first ("why")
- suggestions that preserve autonomy ("try a 24-hour pause", "compare against your own outcomes"), rather than hard "don't buy" statements.
Accomplishments that I'm proud of
The project is privacy-first by design which means it uses no bank data, no surveillance, no tracking - just explicit user feedback. Also, every score comes with a clear factor breakdown. Lastly, I'm proud of its Hackathon-ready reliability: simple dependencies, reproducible setup, demo seeding, and a "judge mode" server.
What I learned
The best "personalization" signal is explicit feedback. It's slower than harvesting data, but it's far more honest and user-controlled. Transparency beats prediction accuracy for decision support. In real life, a model people can understand and challenge is more valuable than a black-box that feels creepy. Windows reliability matters. Dependency fragility can dominate your build time if you pick the wrong stack.
Log in or sign up for Devpost to join the conversation.