Why standard budgeting apps fail, and how i combined Flask, MongoDB Atlas, and failover resilience to build a real-time spending guard.
🎯 1. The Problem: Why Traditional Budget Trackers Fail
Most budget management applications act like passive digital receipts. You spend money, manually log expenses hours later, and only realize you've overspent when your bank balance hits zero.
We built Spendwise to flip this paradigm on its head. Instead of just tracking past expenses, Spendwise acts as an active financial guard—evaluating transactions in real-time , providing an emergency safety buffer, and automating periodic budget rollovers.
🛠️ 2. The Technology Stack
To deliver instantaneous UI feedback and 100% backend reliability, we engineered Spendwise using a modular, decoupled architecture:
Frontend UI Layer: HTML5, CSS3 Glassmorphism System, Vanilla JavaScript (ES6+), and
SWApiREST bridge.Backend REST Engine: Python 3.14, Flask REST API, Gunicorn WSGI server, and APScheduler cron service.
Database & Security: MongoDB Atlas Cloud NoSQL, PyMongo, In-Memory RAM Failover Layer, and BCrypt password hashing.
Infrastructure: Render Cloud Hosting, Procfile launcher, and HTTPS Multi-Gateway Email Routing over Port 443.
🔄 3. How Spendwise Works: External Flow vs. System Engine
Understanding Spendwise comes down to two perspectives: what the user sees on screen, and what the rules engine computes behind the scenes.
🌐 User Experience (External)
Wallet Setup: Configure your balance, period spending limit, and emergency buffer.
Check Before Spending: Input item price before buying to receive instant approval feedback in <0.1 seconds.
Instant Buy & Sync: Deduct funds and watch remaining limit update live.
Email Summary: Trigger detailed financial reports sent directly to your inbox.
⚙️ System Mechanics (Internal Engine)
Rule 1 (Spending Guard): Approves purchase if Item Cost≤Remaining Limit.
Rule 2 (Emergency Buffer Fallback): If limit is exceeded, verifies if Item Cost≤Remaining Limit+Emergency Buffer. Consumes buffer reserve and drops remaining limit to $0.00 to prevent further overspending.
Rule 3 (Periodic Rollover Engine): Automatically carries over unused budget from previous periods when new cycles start.
💡 4. Real-Life Scenario: Meet Alex
Let's look at how Spendwise protects a real user in practice:
Initial Setup: Alex starts with
$1,000Balance,$200Weekly Limit, and$50Emergency Buffer.🟢 Transaction 1 ($40 Headphones): Within limit. Spendwise approves it, leaving
$160limit and$960balance.🟡 Transaction 2 ($180 Laptop Charger): Exceeds
$160limit by$20. Spendwise triggers the Emergency Buffer, absorbing$20from the reserve, setting remaining limit to$0.00, and updating balance to$780.🔴 Transaction 3 ($100 Smartwatch): Alex tries to buy a smartwatch. Since limit is
$0.00and buffer is$30.00, Spendwise declines the transaction, saving Alex from overspending.📩 Transaction 4 (Email Summary): Alex clicks "Send Email Report" and receives a summary in his inbox.
🛡️ 5. Technical Highlights & High Availability
Multi-Gateway HTTPS Email Routing (Port 443 Resilience): Cloud platforms like Render block raw TCP SMTP ports (25, 465, 587). Spendwise uses a resilient HTTPS API cascade: Mailtrap⟶Mailjet⟶SendGrid⟶Brevo⟶Resend
Zero-Downtime Hybrid Database Failover: If cloud MongoDB Atlas is starting up or temporarily unreachable, Spendwise seamlessly activates an In-Memory RAM Store, guaranteeing zero 500 errors during testing.
🔗 6. Links & Resources
🚀 Live Deployed Application: Click Here
💻 GitHub Source Code Repository: Click Here
🎯 6. Key Takeaways
Building Spendwise taught us that great fintech applications aren't just about recording data—they're about protecting user behavior in real-time. By pairing instant UI feedback with resilient serverless architecture, you create a system that users can rely on every day.
Created for the Spendwise Project Documentation.
Top comments (0)