Section 1: The Problem with Spreadsheet Sprawl
Spreadsheets are deceptive. They start out as simple, flexible solutions for tracking almost anything. But as your data grows and you add more tabs, the complexity compounds.
The Hidden Costs of Spreadsheet-Based Organization
The primary issue with relying on spreadsheets for critical personal data isn’t just about organization—it’s about sustainability. Every time you add a new category or want to ask a different question of your data, you’re either modifying formulas or creating entirely new sheets. Over time, this leads to what I call “spreadsheet sprawl.”
Cross-file dependencies become a nightmare. When one spreadsheet references values in another through VLOOKUP or external references, the risk of breaking something during updates increases exponentially. A change in one file can silently break formulas in another without immediate detection.
Update friction is another major problem. When updating your data requires opening multiple files, navigating to the right tabs, and remembering which cells to modify, you’re far less likely to maintain the system consistently. And inconsistent data is often worse than no data at all.
Data silos prevent you from seeing the big picture. Your net worth doesn’t exist in isolation from your goals, and your physical assets are part of your overall financial picture. When these datasets live in separate files, you miss the connections between them.
What I Needed: A Single Source of Truth
The goal was simple: one place to answer all my financial and life-tracking questions without hunting through tabs and files. I needed:
Real-time net worth across every account
Progress tracking against financial and life goals
Consolidated view of physical and digital assets
A wishlist that automatically feeds into collections when items are purchased
Maturity tracking for CDs and other time-bound investments
This required moving beyond spreadsheets without losing the flexibility they provided.
Section 2: Architecture Overview—Excel as a Database
The most controversial decision in this architecture is using Excel as the database. Yes, it sounds like something from the 1990s. But for a single-user personal application, it has surprising advantages.
Why Excel Instead of a Traditional Database?
Portability is the biggest win. The data model is a single .xlsx file, with one sheet per entity. On the desktop version, this file lives locally on your machine. On the web version, it’s stored in Azure Blob Storage behind GitHub OAuth.
No schema migrations means zero downtime or complex upgrades. If you need to add a new column, you open the file in Excel, add it, and the app adapts. There’s no ORM, no migration scripts, and no hosted PostgreSQL bill for a hobby app.
Ad-hoc analysis becomes trivial. You can open the file in Excel any time you want to sanity-check data, run pivot tables, or do custom analysis. This flexibility is powerful for personal finance.
Backup simplicity means copying one file. Compare this to backing up a database with multiple tables, indexes, and configuration. One file, one backup.
Cost is almost negligible. Hosting the web version costs about $0.01 per month in Azure fees. That’s not a typo.
The ExcelJS Data Layer
The app uses ExcelJS for reading and writing the Excel file. This Node.js library handles the file I/O and provides a clean API for working with sheets, rows, and columns.
The abstraction layer is simple but powerful. Every page component calls onSave(sheetName, row) or onDelete(sheetName, rowIndex). The underlying implementation handles whether this becomes an Electron IPC call (desktop) or a fetch('/api/save-row') call (web).
This abstraction means the same React components work in both environments. You build the UI once, and the storage layer adapts based on the runtime environment.
The Tech Stack Breakdown
Layer Technology
Desktop Shell Electron
Web Host Azure Static Web Apps
API Azure Functions v4 (Node.js)
UI React + Vite
Web Data Storage Azure Blob Storage (.xlsx)
Desktop Data Storage Local .xlsx
Excel Read/Write ExcelJS
Charts Recharts
Styling Tailwind CSS
Web Authentication GitHub OAuth (Azure Static Web Apps)
This stack was chosen for simplicity and ease of maintenance. It leverages modern front-end tooling while keeping the backend as minimal as possible.
Section 3: Application Features and Architecture
The app organizes data into five main sections, each addressing a specific aspect of personal tracking.
Finance Module
The Finance section is the most complex, pulling data from multiple sheets to provide a comprehensive financial picture:
Dashboard: Net worth summary, historical net worth trends, asset allocation breakdown, and upcoming CD maturities.
Budget: Income and expenses organized by category and frequency.
Allocation: Target vs. actual asset class mix to track drift from investment plans.
Projection: Compound growth projections for each asset and income source with per-asset growth-rate assumptions.
Account Management
This section tracks all financial accounts:
Accounts: Every bank, investment, retirement, and HSA account with full value history over time.
CDs: Certificate of deposit tracker with maturity calendar and blended APY.
Crypto: Holdings with staking status, APY, and unlock dates.
Retirement: Holdings, fund allocation, and withdrawal schedule.
Donations: Charitable giving log by year and organization.
Debts: Mortgage, auto, student loans, and credit cards with collateral values, equity calculations, and rewards tracking.
Asset Management
Physical and digital assets are tracked separately:
Tangible Assets: Physical collections (books, vinyl, art) with cost basis and current value.
Digital Assets: E-books, digital games, and similar digital inventory.
Life Tracking
This section handles non-financial aspects:
Goals: Financial goals, lifetime goals, and education/certification roadmap.
Achievements: Awards and personal milestones.
Tasks: To-do list with priority, categories, and due dates.
Research: Saved links and reference material by category.
Media: Reading, gaming, and film logs with ratings.
Wishlist: Cross-category wish list with automatic transfer to matching collections when marked “Purchased.”
Personal Information
Contacts: Address book with relationships and birthdays.
Personal Info: Personal details.
Demo Mode
A demo mode toggle in the sidebar swaps in sample data instantly. This is invaluable for taking screenshots or demoing the app without exposing personal data.
How to Add a New Tab: A Repeatable 5-Step Process
One of the most valuable aspects of this architecture is how easy it is to add new data categories. The process is standardized and repeatable.
Step 1: Define Columns in SHEET_COLUMNS
The column definitions live in the SHEET_COLUMNS constant. This is the source of truth for what data each sheet contains and how it should be displayed.
For a new “Subscriptions” tracker, you’d define columns like:
Subscriptions: [
'Name',
'Category',
'MonthlyCost',
'AnnualCost',
'BillingDate',
'PaymentMethod'
]
Step 2: Update Sheet Mapping
The sheet mapping connects the logical sheet name to the actual Excel sheet. This is where you define which sheet in the Excel file corresponds to which data entity.
Step 3: Create React Components
Each sheet needs a component that renders the data in a useful way. This could be a table, a grid, a chart, or any other visualization. The components use the abstraction layer to read and write data, so they don’t care whether they’re running on desktop or web.
Step 4: Add to Sidebar Navigation
The new section needs to be accessible from the sidebar. This means updating the navigation configuration with the new route and icon.
Step 5: Initialize the Sheet
The app should handle creating the sheet in the Excel file if it doesn’t already exist. This initialization should set up the correct columns and any initial data.
This repeatable process is why the app now has 20+ tabs covering everything from financial accounts to media logs. Once the pattern is established, adding new functionality takes minutes.
Best Practices
Start with Data Portability
Building your personal app around a portable data format like Excel means you’re never locked into a specific platform or hosting provider. The data remains accessible and usable even if you stop maintaining the app.
Abstract Your Storage Layer
The src/api.js abstraction in this project is the key architectural decision. It decouples the UI from the storage mechanism. This makes it easy to switch from local file storage to cloud storage or even to a traditional database later.
Use Well-Known Libraries
ExcelJS, React, and Electron are mature, well-documented libraries with active communities. Choosing established tools reduces risk and makes it easier to find solutions to problems.
Standardize New Feature Addition
Having a repeatable process for adding new features encourages you to actually build them. If every new tab requires significant architectural work, you’ll create far fewer of them.
Common Mistakes
Using Excel for Multi-User Applications
Excel is a terrible choice for any application with multiple concurrent users. There’s no built-in conflict resolution, no transaction support, and no access controls. This architecture only works for single-user applications.
Not Backing Up the Data
One of the benefits of using a single file for data is that backup is simple. But simplicity doesn’t help if you don’t actually back up. Ensure you have a backup strategy, whether it’s automatic cloud sync or regular manual copies.
Overcomplicating the Architecture
It’s easy to look at this stack and think “I need a proper database, a proper backend, and a REST API.” That’s overengineering for a personal project. The minimal architecture keeps costs near zero and maintenance minimal.
Final Thoughts
Building a personal finance and life-tracking app using Excel as a database isn’t conventional, but it’s pragmatic. The architecture prioritizes data portability, low maintenance, and ease of use over traditional database features that aren’t needed for a single-user application.
The key takeaway is that the best architecture for a project depends on its scale and audience. For a personal productivity tool serving a single user, this approach is hard to beat. It costs pennies per month, requires minimal maintenance, and gives you complete control over your data.
If you’re currently drowning in spreadsheets, consider whether a unified app might be the answer. The investment in building it will pay off in time saved and insights gained. And with a repeatable process for adding new features, you’ll find yourself tracking more of what matters.
Have you built your own personal tracking tools? What unconventional tech choices have worked well for you? Share your experiences in the comments.
Top comments (0)