Everyone says you need a backend. User auth, database, API endpoints — the standard checklist before writing a single line of product code.

I skipped all of it.

I built DonFlow, a budget planner that runs entirely in your browser. No server, no signup, no tracking. Your financial data never leaves your device. And the journey taught me things I didn't expect.

Why Zero Backend?

The idea was simple: a tool that compares your planned budget vs actual spending. Like a financial GPS that shows where you drifted.

But here's the thing about finance apps — people are paranoid about their data (rightfully so). Every cloud-based budgeting tool asks you to trust them with your bank transactions. I wanted to eliminate that trust requirement entirely.

The rule: If the data never leaves the browser, there's nothing to breach.

The IndexedDB Reality Check

IndexedDB is powerful but... weird. Here's what surprised me:

1. It's Not Just localStorage With Extra Steps

I initially thought IndexedDB was overkill. "Just use localStorage!" But financial data has relationships — categories contain items, months reference budgets, transactions link to categories.

I used Dexie.js as a wrapper, and it turned IndexedDB into something that actually feels like a database:

// Define schema with relationships
const db = new Dexie('donflow);
db.version(1).stores({
  budgets: '++id, month, year,
  categories: '++id, budgetId, name, type,
  transactions: '++id, categoryId, date, amount
});

The tradeoff? No server-side queries means all filtering and aggregation happens in the browser. For a personal finance app with maybe 10,000 transactions, this is totally fine. For anything bigger, you'd feel the pain.

2. Data Import Is the Hardest Problem

Without a backend, users need to get data in somehow. I built a universal CSV/XLSX parser that auto-detects bank formats:

• It scans all sheets in an Excel file (some banks put summary on sheet 1, transactions on sheet 2)
• It looks for date + amount column patterns across 10+ Korean bank formats
• It handles encoding issues (Korean CSV files love EUC-KR)

This single feature took more time than the entire budget visualization system. Lesson: the boring plumbing is where users actually get stuck.

3. Privacy Architecture Changes Everything

When there's no server, entire categories of problems disappear:

• ✅ No auth system to build or maintain
• ✅ No GDPR compliance (data never touches your servers)
• ✅ No hosting costs that scale with users
• ✅ No database backups to manage
• ✅ No security audits for data at rest

But new problems appear:

• ❌ No password reset (there's no password)
• ❌ No cross-device sync (your data lives on this browser, period)
• ❌ No analytics on usage patterns (you literally can't see what users do)
• ❌ Harder to debug user issues (you can't look at their data)

The "Plan vs Reality" Insight

The core concept — showing planned budget alongside actual spending — seems obvious in hindsight. But most budgeting apps only track spending after it happens. They're rear-view mirrors.

What people actually need is a dashboard of drift: "I planned to spend ₩500,000 on food this month. I've spent ₩420,000 and it's only the 20th."

That context changes behavior. A number in isolation (₩420,000) means nothing. A number against a plan (₩420,000 / ₩500,000 with 10 days left) tells a story.

What I'd Do Differently

1. Start with data import, not visualization. I built beautiful charts first, then realized users couldn't get their data in. Build the pipeline before the dashboard.

2. Test with real bank files earlier. Every bank exports slightly differently. I tested with mock data for weeks, then spent days fixing edge cases with real exports.

3. Don't underestimate noscript SEO. An SPA with no server-rendered content is invisible to search engines by default. I had to add a comprehensive noscript section with full feature descriptions and FAQ.

Is Zero-Backend Right for Your Project?

Ask yourself:

• Is user data sensitive? (finance, health, personal notes)
• Does it need to work offline?
• Are you a solo dev who doesn't want to manage infrastructure?
• Is the dataset small enough to live in a browser?

If yes to most of these, browser-only might be your sweet spot. The architecture is liberating — deploy to GitHub Pages and forget about it.

If you need collaboration, real-time sync, or datasets over ~100MB, you'll want a backend.

TL;DR

Building browser-only taught me that constraints breed creativity. No server forced me to solve data import elegantly. No auth forced me to make onboarding instant. No tracking forced me to trust that if the tool is useful, people will come back.

The app is free and open source: DonFlow on GitHub

📖 Series: Building a Finance App With No Server

1. → You are here — I Built a Finance App With Zero Backend — Browser-Only Architecture
2. Why I Chose IndexedDB Over a Backend
3. Storing Financial Data in the Browser: IndexedDB + Dexie.js Guide
4. Share Your Web App State via URL — No Backend Required
5. What I Learned After 2 Weeks of Building

📘 Free Resource

If you are building with a $0 budget, I wrote a playbook about what works, what doesn't, and how to think about the $0 phase.

📥 The $0 Developer Playbook — Free (PWYW)

Want the deep dive? The Extended Edition ($7) includes a 30-day launch calendar, 5 copy templates, platform comparison matrix, and revenue math calculator.