Thrive

Built for students who've checked their balance and immediately regretted it. Know where it goes. Know how long it lasts. This is student life sorted to survive the semester

Comment

Thrive — Project Story

More month than money? Not anymore.

Inspiration

It started with a WhatsApp message.

A friend texted me mid-month: "bro how do I have only ₹800 left, I literally just got paid." No dramatic purchase, no emergency — just the slow, invisible drain of Swiggy orders, Uber rides, and UPI transfers that individually felt tiny but collectively wiped out an entire salary.

That moment stuck with me. Most personal finance tools are built for people with EMIs, mutual funds, and tax brackets to worry about. Students don't need that. We need something that looks at our bank statement and answers one question honestly: how long will this money last?

That's what Thrive is. A no-setup, no-account, no-judgment financial companion built specifically for students living paycheck to paycheck — or stipend to stipend.

What it does

Thrive takes your bank statement CSV and turns it into clarity.

Upload your file and within seconds you get:

  • Survival prediction — based on your actual burn rate, Thrive tells you exactly how many days your current balance will last and flags whether you're SAFE, WARNING, or in DANGER of running out before month-end
  • Automatic categorisation — transactions are sorted into Food & Dining, Transport, Shopping, Entertainment, Essentials, and Subscriptions using keyword matching against common Indian apps and merchants (Swiggy, Zomato, Uber, Amazon, Airtel, and more)
  • Behavioural insights — patterns you wouldn't notice yourself: are you spending more on weekends? Is one recurring amount showing up suspiciously often? Are small purchases eating a bigger share than you think?
  • Smart advisory — plain-language suggestions tailored to your actual data, not generic budgeting advice
  • Manual tagging — unknown UPI transfers that couldn't be auto-categorised can be labelled by you and folded into the breakdown
  • CSV export — your cleaned, categorised statement ready to download

Everything runs locally. Nothing is stored, sent, or logged.

How we built it

Thrive is built entirely in Python using Streamlit for the interface, pandas for data processing, and matplotlib for the spending chart.

The architecture is intentionally simple — no database, no backend, no login. The entire app is a single app.py file deployed on Streamlit Community Cloud.

The core logic works in three passes:

1. Parsing The CSV parser normalises column names and uses heuristic matching to find the date, description, amount, type, and balance columns — regardless of what the bank chose to call them. It handles comma-formatted numbers, rupee symbols, and mixed date formats gracefully.

2. Categorisation Each transaction description is lowercased and matched against a keyword dictionary. The burn rate is computed as:

$$\text{Burn Rate} = \frac{\text{Total Spend (last 30 days)}}{\text{Number of Active Days}}$$

And survival is projected as:

$$\text{Days Left} = \left\lfloor \frac{\text{Current Balance}}{\text{Burn Rate}} \right\rfloor$$

Risk level is assigned by comparing days left against the remaining days in the current month, with a ±7 day buffer for SAFE and a ±3 day buffer for WARNING.

3. Insights Behavioural patterns are derived from the parsed data — weekend vs weekday spend ratios, frequency of sub-₹200 transactions, repeated exact amounts, and category share percentages.

The UI is styled with custom CSS injected via st.markdown, using the Fraunces and DM Sans typefaces, a soft grid background, and a deliberate light-mode-first design to avoid Streamlit's default dark theme conflict.

Challenges we ran into

The dark theme problem was the first wall we hit. Streamlit picks up the OS-level dark mode preference and overrides custom CSS — making buttons render black-on-black and table text disappear entirely. The fix required both a config.toml theme lock and surgical CSS overrides that targeted Streamlit's specific data-testid attributes without leaking into the dataframe iframe internals (which render in their own color context and break if you apply color: !important globally).

CSV inconsistency was a bigger challenge than expected. Every Indian bank exports statements differently — HDFC uses "Withdrawal Amt.", SBI uses "Debit", Axis uses "Dr" in a type column, some don't have a type column at all. The parser needed to be flexible enough to handle all of these without asking the user to configure anything.

The month-end bug was subtle. The original survival calculation used today.replace(day=28) as a proxy for month-end — which works in March but produces wrong risk classifications in January (31 days), February (28/29 days), and any day after the 28th. Replaced with a proper last-day-of-month calculation using the first day of the next month minus one day.

Balance detection had an edge case: we originally used 0.0 as the sentinel value for "balance not found," which meant users with a genuine ₹0 balance were incorrectly prompted to enter it manually every time. Changed to None as the sentinel so the distinction is clean.

Accomplishments that we're proud of

  • Zero configuration — drop in any CSV from any major Indian bank and it just works
  • The survival number — a single, honest figure that tells you something no other student finance tool surfaces so directly
  • Privacy by design — there is no server, no account, no data retention. Your statement never leaves your browser session
  • The CSS architecture — getting a fully custom-styled UI on top of Streamlit without breaking any of its native widget behaviour was genuinely hard, and we're happy with how it turned out
  • It's actually useful — we tested it on real statements and the insights hold up. The weekend spend flag and small-purchase accumulation warnings caught things people hadn't noticed themselves

What we learned

  • Streamlit is powerful for rapid prototyping but its theming system requires careful handling — the iframe-based dataframe renderer is isolated from the main document's CSS cascade, and treating it like a regular DOM element breaks things in non-obvious ways
  • Real-world CSVs are messier than any spec suggests. Defensive parsing — with fallbacks at every step — is not optional
  • The most useful insight is often the simplest one. "Your money runs out on the 22nd" is more actionable than any pie chart
  • Python's pandas date handling is robust but requires explicit dayfirst=True for Indian date formats (DD/MM/YYYY), otherwise transactions get silently misread
  • Designing for a specific user (broke students) is more useful than designing for everyone

What's next for Thrive

  • UPI app integration — pull transactions directly via the NPCI ecosystem instead of requiring a CSV export
  • Multi-month view — compare spending across months to surface trends, not just point-in-time snapshots
  • Smart savings goals — "if you cut food spend by 20%, you save ₹X by the end of semester"
  • Hostel mode — shared expense tracking for roommates splitting rent, groceries, and electricity
  • Nudges — optional end-of-week spending summaries sent via WhatsApp or email
  • Broader bank support — pre-built parsers for the top 10 Indian banks so even edge-case CSV formats are handled perfectly out of the box

The core belief behind Thrive doesn't change though: financial clarity shouldn't require a finance degree. It should take thirty seconds and a CSV file.

Built With

Share this project:

Updates