FIRE Tracker Promises 'Comprehensive Personal Finance and Wealth Management Tool'—What Features Would a Beancount-Native FIRE Dashboard Need?

General
1

I’ve been diving deep into FIRE tracking tools lately, and I keep seeing FIRE Tracker, ProjectionLab, and Fireleap praised as “comprehensive personal finance and wealth management tools” with everything you need to track your path to financial independence. Beautiful dashboards, automatic net worth updates, Monte Carlo simulations showing the spectrum of possible outcomes, goal tracking showing exactly when you hit your FI number—the works.

But here’s what bugs me: I already have all this data in my Beancount ledger. Every transaction categorized, every asset tracked, complete investment history going back 4+ years. The raw data is there. What’s missing is the FIRE-specific visualization and analysis layer on top of it.

What FIRE Tools Offer (That Fava Doesn’t)

Looking at what these tools provide:

  1. FI Progress Visualization: Current net worth vs your FI number, time to FI at current savings rate, visual progress bars showing how close you are
  2. Savings Rate Tracking: Monthly savings rate, rolling 12-month average, historical trends
  3. Investment Performance Attribution: Which accounts are contributing most to growth, asset allocation drift, rebalancing suggestions
  4. Tax Optimization Suggestions: Roth conversion opportunities based on your actual income, tax-loss harvesting candidates
  5. Spending Trends: Categories increasing/decreasing over time, seasonal patterns, lifestyle inflation detection
  6. Scenario Comparison: What if I save $500 more per month? What’s the difference between coast FIRE, barista FIRE, and lean FIRE based on MY actual numbers?

Fava gives us beautiful account balance visualizations and commodity charts, but it’s not FIRE-oriented. It doesn’t automatically calculate:

  • My current savings rate this month
  • How many years until I hit my FI number
  • Whether I’m on track for my target retirement date
  • What happens if I reduce expenses by $200/month

The Question: What Would a Beancount-Native FIRE Dashboard Need?

If we were building a “FIRE Dashboard” plugin for Fava (or standalone tool reading Beancount files), what features would be table-stakes (must have to be useful) vs nice-to-have (would be cool but not essential)?

My thinking:

Table-stakes features:

  • Net worth tracking over time (this exists in Fava already)
  • Savings rate calculation (Income - Expenses) / Income, with historical trend
  • FI number calculator and progress tracker
  • Years to FI projection based on current savings rate
  • Spending by category with trends

Nice-to-have features:

  • Monte Carlo simulations (like ProjectionLab)
  • Tax optimization suggestions
  • Portfolio rebalancing alerts
  • Mobile-responsive interface
  • What-if scenario modeling

Technical Implementation Questions

For anyone who’s thought about building this:

  1. What’s technically feasible with Beancount data alone? Everything above? Or does some stuff require external data (market projections, tax law changes)?

  2. Should this be a Fava plugin (integrated web UI), standalone dashboard (separate web app reading Beancount file), or script library (Python scripts generating reports you view in browser)?

  3. Who would build this? One passionate developer scratching their own itch? Community collaboration? Funded project?

What I’m Using Today (The Hacky Workaround)

Right now I’m using a mix:

  • Beancount/Fava for all raw data and basic reports
  • Custom BQL queries exported to CSV, then imported into Google Sheets for FIRE-specific calculations (savings rate trends, FI progress chart)
  • ProjectionLab sandbox for scenario modeling, but manually entering data that already exists in Beancount
  • Excel for Monte Carlo simulations using historical return data I query from Beancount

It works, but it’s janky. I’m manually copying numbers between systems, risking data entry errors, and losing the single-source-of-truth that Beancount gives me.

The Real Question

If you could have ONE additional FIRE feature built into Fava or as a companion tool, what would it be?

For me, it would be automatic savings rate tracking with historical trends and projections. Just show me: “You saved 42% this month, 38% trailing 12-month average, if you maintain this you’ll hit FI in 8.3 years.” That alone would be worth its weight in gold.

What am I missing? What FIRE metrics do you track manually that you wish were automated? Would you pay for a professionally developed FIRE dashboard if it integrated seamlessly with Beancount?

2

This resonates deeply—I’ve been on the same journey for the past 2 years!

Started with spreadsheets, graduated to Beancount, and now I’m in that awkward middle phase where I have amazing data granularity but terrible FIRE-specific insights. Like you, I’m exporting to Google Sheets monthly to calculate things that SHOULD be automatic.

What I Actually Built (Small Win)

I wrote a Python script that reads my Beancount file and generates a simple HTML dashboard with:

  • Monthly savings rate (trailing 3, 6, 12 months)
  • Net worth trend chart (powered by matplotlib)
  • Spending breakdown by major category
  • “Years to FI” calculation assuming current savings rate continues

It’s about 200 lines of Python using the Beancount API. Takes 3 seconds to run, outputs to fire_dashboard.html that I open in my browser. Updates whenever I run the script (usually weekly when I update my ledger).

The good: It’s fast, uses my actual data, no manual data entry.
The bad: It’s a static HTML file (not integrated into Fava), requires running script manually, looks ugly (my CSS skills are terrible), and has zero interactivity.

But honestly? Even this simple dashboard has been life-changing for me. Seeing my savings rate trend over 24 months was eye-opening—I thought I was consistently hitting 35-40%, but the data showed huge swings (52% some months, 18% others). That insight alone helped me identify problem months (always December and July—holiday travel and summer vacation).

On Table-Stakes vs Nice-to-Have

I’d actually flip one of your categorizations:

You listed savings rate tracking as table-stakes and what-if scenario modeling as nice-to-have. I think it’s the opposite for serious FIRE folks.

Why: Savings rate is easy to calculate manually (I know roughly what I saved this month). What’s HARD is answering: “If I move to a lower cost-of-living city and cut housing from $2800 to $1600/month, how much faster do I hit FI?” That requires modeling multiple scenarios with different expense assumptions—and that’s where commercial tools shine but Beancount falls short.

ProjectionLab’s scenario builder is honestly incredible for this. You can clone your base plan and tweak variables (move to LCOL area, get a raise, have kids, pay off mortgage early), and immediately see the impact on FI date. That’s the killer feature I’d want in a Beancount-native tool.

What I’d Pay For

You asked if I’d pay for a professionally developed FIRE dashboard. Absolutely yes, if it met these criteria:

  1. Seamless Fava integration (not a separate app I have to context-switch to)
  2. Privacy-preserving (reads my local Beancount file, no cloud upload)
  3. Configurable (I can define what “FI” means—25x annual spending? 30x? Custom number?)
  4. Scenario modeling built-in (the ProjectionLab killer feature)

I’d pay $50-100 one-time, or $5-10/month subscription if actively developed.

Implementation Suggestion

For technical approach, I vote for Fava plugin rather than standalone tool. Reasons:

  • Already familiar with Fava interface
  • No context switching (Fava already has my financial data open)
  • Can leverage existing Fava authentication/security
  • Community is already comfortable installing Fava plugins

The fava-dashboards plugin shows this is technically feasible—it creates custom dashboards with TypeScript frontend. A FIRE dashboard could use the same architecture.

Happy to share my hacky Python script if anyone wants to use it as a starting point!

3

Coming from the developer side (DevOps background, new to personal finance), I have some thoughts on the technical architecture question.

Why a Fava Plugin Makes Sense (From a Dev Perspective)

You mentioned three possible approaches: Fava plugin, standalone dashboard, or script library. As someone who loves plain text and automation, here’s my take:

Fava plugin wins because it solves the “deployment” problem. Think about it:

  • Beancount users already have pip install fava in their setup
  • They already run fava main.beancount as part of their workflow
  • Adding a FIRE plugin would just be pip install fava-fire + one config line
  • No additional services to manage, no separate web server to run

Compare that to a standalone dashboard that requires running its own web app, managing dependencies, keeping it updated separately. That’s fine for developers, but creates friction for non-technical FIRE folks who just want to track finances.

What’s Technically Feasible

Regarding your question about what’s possible with Beancount data alone:

Definitely feasible:

  • Savings rate calculations (pure math on Income/Expenses)
  • Net worth trending (account balances over time)
  • Spending analysis (query transactions by category, time period)
  • FI progress tracking (compare net worth to target)
  • Historical return analysis (price changes on investment commodities)
  • Actual allocation vs target allocation

Would need external data:

  • Future market return projections (for Monte Carlo)
  • Tax law changes (for optimization suggestions)
  • Inflation assumptions (for real return calculations)

But here’s the thing: even without external data, you could use historical data as a proxy. For Monte Carlo simulations, you could randomize based on YOUR actual portfolio’s historical volatility. That’s arguably more accurate than using generic “market returns 7%” assumptions.

The Developer Workflow Parallel

This feels very similar to how we approached observability in DevOps:

Phase 1: Raw logs (like raw Beancount transactions)
Phase 2: Metrics and dashboards (what we need for FIRE tracking)
Phase 3: Alerting and automation (imagine: “You’re trending toward FI date slipping by 6 months, consider reviewing Q2 spending”)

Beancount gives us Phase 1 perfectly. We’re missing Phase 2 (dashboards). Phase 3 would be amazing but is probably overkill initially.

My Wishlist Feature: Git Integration

One feature I haven’t seen mentioned: show FIRE metrics alongside git commits.

What if the FIRE dashboard could correlate major financial changes with git history? Like:

  • “Savings rate dropped from 45% to 32% after commit abc123 (added new recurring subscription)”
  • “Net worth growth accelerated after commit def456 (increased 401k contribution)”

This would make financial decisions more visible and reversible—the exact same philosophy as version control for code. Did a lifestyle change hurt your FI timeline? The git diff would show exactly what changed.

I know this is niche (appeals to developer-accountants like me), but it feels very “Beancount philosophy” to me.

Would I Build This?

Honestly, I’m tempted to start hacking on this as a learning project. I need to get better at Beancount anyway (just migrated from spreadsheets 6 weeks ago), and building a tool is how I learn best.

If a few other people were interested in collaborating, I’d be down for a weekend hack session. Even if we just built a proof-of-concept showing savings rate + FI progress, that’d be useful for the community and a good foundation for others to build on.

Anyone interested in a GitHub repo to start prototyping?

4

Chiming in from the professional bookkeeping side—I work with small business clients, not FIRE folks, but the “visualization gap” problem is universal.

The Reporting Reality Check

Here’s what I’ve learned helping 20+ small businesses transition to Beancount: clients don’t care about raw data, they care about answers to specific questions.

For small business owners, those questions are:

  • “Am I making money this month?”
  • “Can I afford to hire someone?”
  • “Why is my bank balance going down even though we’re profitable?”

For FIRE folks, I imagine it’s similar:

  • “When can I retire?”
  • “Am I on track?”
  • “What happens if I quit my job next year?”

Beancount + Fava gives you all the data to ANSWER these questions, but it requires you to:

  1. Know what BQL query to write
  2. Export the data
  3. Build the visualization yourself
  4. Interpret the results

That’s too many steps. The dashboard should answer the question directly.

What I Tell Clients (Applies to FIRE Too)

When clients ask “should I use Beancount or just pay for QuickBooks,” I explain the trade-off:

QuickBooks has pre-built reports (P&L, balance sheet, cash flow) that are pretty good for 80% of businesses. But the other 20%? You can’t customize them. You’re stuck with what Intuit decided you need.

Beancount has infinite flexibility—you can answer ANY question about your finances. But that requires work: writing queries, building reports, understanding the data structure.

For FIRE tracking, it sounds like you need something in between:

  • More structured than raw BQL queries
  • More flexible than rigid commercial FIRE tools

That’s exactly what a well-designed plugin/dashboard could provide: opinionated defaults that cover 80% of use cases, with escape hatches for custom analysis.

Feature Prioritization Framework

You asked what features are table-stakes vs nice-to-have. Here’s how I’d prioritize:

P0 (Must have in v1):

  • Savings rate (monthly + rolling average)
  • Net worth trend
  • FI number progress bar
  • Years to FI (simple projection)

P1 (Important but can wait for v2):

  • Spending breakdown by category
  • Investment performance attribution
  • Historical comparison (“am I doing better this year than last year?”)

P2 (Nice to have eventually):

  • Scenario modeling
  • Monte Carlo simulations
  • Tax optimization suggestions
  • Mobile responsive design

The reason P0 is so minimal: ship something useful quickly, get feedback, iterate. Don’t spend 6 months building the perfect FIRE dashboard that has every feature but never launches.

Payment Question

You asked if people would pay. I think the answer depends on:

One-time purchase: $50-150 depending on feature completeness. I’d pay $100 for a solid v1 with P0 features working well.

Subscription: Only if there’s ongoing value (regular updates, new features, support). Otherwise subscription feels weird for a local tool that doesn’t have hosting costs.

Open source + paid support: This might be the best model. Core tool is free/open source, but you can pay for professional setup, custom features, or priority support.

Realistic Assessment

Here’s my slightly cynical take: this probably won’t get built unless someone REALLY needs it for themselves.

Most community projects die because they’re “nice to have” for many people but not “must have” for anyone. The projects that succeed are built by someone solving their own problem who also happens to share it with others.

So the real question is: is there someone out there who needs this badly enough to build v0.1 themselves, even if it’s rough? That person becomes the maintainer, others contribute improvements, and eventually it becomes solid.

Is that you, @finance_fred? :blush: