Why Most Expense-Tracker fail (And how I'm Building Spendly to Fix It)

We've all been there: you download a shinny new finance app, spend 20 minutes setting up your account, diligently log every coffee for three days and then completely abandon it by day four.
Why does this keep happening? Because standard budgeting apps are broken.
Most Expense trackers force you into "form fatigue" demanding six dropdown selections(account, merchant, category, date, tag, notes) just to log a $3 expresso. On top of that, they give you passive, rear-view-mirror data. Showing a pie chart that says "you spent 40% of your money on food last month" doesn't help when the money is already gone.
I started building Spendly **to solve this exact problem: **to eliminate manual friction and transform passive data into actionable financial clarity.
While the app is actively in development, the core full-stack foundation is live and functional. Here is how i structured the application, what is built so far and where it's headed.

The Tech Stack
To keep the application fast, secure and predictable, I xhose a modern full-stack setup:

• Backend : Go(Golang) + GORM ORM
• Frontend : React + TypeScript _ Tailwind CSS
• Authentication : Cookie-based JWTs (spendly_token)
• Database: SQLite for rapid local development (migratable to PostgreSql via GORM)

What We've Built so far
Instead of overwhelming users with dense menus, Spendly focuses on a clean layout where every takes a single click or keypress.

1. Secure, Frictionless Auth(GO + JWT Cookies
   To make security to the user, authentication relies on HTTP-onyly JWT cookies (spendly_token). This avoids storing sensitive tokens in localStorage and ensures every API request automatically validates the user's session without extra client-side headers.

2. A Clean Visual Dashboard
   The main dashboard gives you an instant snapshot of your financial health the second you log in:

• Key Metric Cards: Instant visibility into Total Spent (with month-over-month trends)
• , Budget Used (showing exact remaining dollars),Transaction Count, and a calculated Budget Health Score.
• Visual Spending Trends : An SVG-rendered line chart mapping out 6-month spending arcs so you can spot spikes at a glance.
• Category Health Bars: Color-coded progress bars comparing real-time spend against monthly caps across categories like Food & Drink, Transport and Utilities

1. Expense Managment with Real-Time Feedback The dedicated Expenses view replaces statis lists with an interactive workspace:

• Instant Client-Side Search: Search by description in real-time as you type.
• Category Pill Filters: Filter transactions instantly with single-tap category tabs.
• Inline Creation: Add new expenses via an overlaid modal without losing your place or waiting for page reloads.

• Instant Deletion: Clickable * action linked directly to the Go backend for immediate database cleanup.

  Code Spotlight: Secure Item Deletion in GO
  One critical detail when building muilti-tenant financial apps is ensuring strict data isolation.Here is how the Go backend handles deleting an expense - verifying both the transaction ID and the user's session in a single query:
  

func (h *ExpenseHandler) DeleteExpense(w http.ResponseWriter, r *http.Request) {
    // 1. Authenticate user via JWT Cookie
    user, err := utils.GetUserFromCookie(r, h.DB, h.JWTKey)
    if err != nil {
        w.WriteHeader(http.StatusUnauthorized)
        return
    }

    // 2. Extract resource ID from the URL path
    expenseID := r.PathValue("id") 

    // 3. Delete ONLY if the expense ID matches AND belongs to the logged-in user
    result := h.DB.Where("id = ? AND user_id = ?", expenseID, user.ID).Delete(&models.Expense{})
    if result.Error != nil || result.RowsAffected == 0 {
        http.Error(w, "Expense not found or unauthorized", http.StatusNotFound)
        return
    }

    w.WriteHeader(http.StatusOK)
}

The roadmap: What's coming Next?

The current build solves the visual and structured base but the ultimate goal for Spendly is Zero friction tracking. The next development sprints will focus on:

1. Natural Language Processing (NLP): Allowing users to log by typing or speaking:_ "spent $14 on sushi for lunch yesterday"_ and letting the app parse the dollar amount, date and category automatically.
2. Receipt OCR scanning: Snapping a photo of a reciept to automatically extract vendors, line items and tax.
3. Daily "safe-to-Spend" Allowance: Replacing boring historical pie chart with proactive daily guidance.

What is the biggest thing that makes you abandon budgeting apps? I'd love to hear your thoughts, feedback on the GO/React architecture or feature sugestions in the comment section bellow!