When Fava's Beautiful UI Isn't Enough: Building Custom Dashboards for Client-Specific Needs

finance_fred · March 29, 2026, 1:47am

Fava is gorgeous. Seriously—when I first discovered it after years of spreadsheet hell, I felt like I’d found financial tracking nirvana. The charts, the filtering, the clean transaction views… it’s everything you need for personal finance tracking.

Until it isn’t.

The Day a Client Asked for Something Fava Couldn’t Do

I run a side consulting business helping FIRE-focused professionals optimize their path to early retirement. Last month, a client asked for a dashboard that Fava simply can’t provide out-of-the-box:

Requirements that broke Fava:

Net worth trajectory with multiple scenarios: Side-by-side comparison of CoastFIRE (stop saving, let it grow), LeanFIRE ($30K/year expenses), and FatFIRE ($100K/year) paths
Tax-optimized withdrawal sequence visualization: Which accounts to tap first (taxable → Roth conversions → traditional IRA) with projected tax brackets over 30 years
Geographic arbitrage calculator: Living cost comparison between Seattle, Portugal, and Thailand with currency-adjusted purchasing power

Fava gives me beautiful historical data. But it’s not built for forward-looking scenario modeling with custom business logic.

The Plain Text Accounting Advantage Nobody Talks About

Here’s what I realized: Beancount isn’t just an accounting tool—it’s a single source of truth that ANY visualization layer can consume.

With QuickBooks or Xero, you’re locked into their UI. If their dashboard doesn’t show what you need, you’re out of luck (or paying $$$$ for their “advanced analytics tier”).

With Beancount plain text:

Fava reads it and gives me gorgeous standard dashboards
My custom Python scripts read the SAME ledger for specialized analysis
Future tools (maybe GPT-7 in 2027?) can read it too
The data layer never changes—only the presentation layers evolve

My Technical Stack for Custom FIRE Dashboards

Tools I use:

bean-query for data extraction: bean-query ledger.beancount "SELECT account, sum(position) WHERE account ~ 'Assets:' GROUP BY account"
Pandas for data manipulation: Time-series projections, scenario modeling, currency conversions
Plotly for interactive charts: Clients can hover, zoom, toggle scenarios on/off
Jupyter notebooks as “living dashboards”: Update the ledger, re-run cells, charts refresh automatically

Example workflow:

Morning: Add transactions in Beancount plain text (or use Fava for quick entry)
Client check-in: Open Jupyter notebook, run all cells → fresh dashboard with today’s data
Client sees: “You’re 67% to CoastFIRE, need $43K more before you can stop contributing”

The notebook lives in Git alongside the ledger. Every calculation is documented and version-controlled.

The Honest Trade-Off: Maintenance Burden

Here’s what I tell people who ask if they should build custom dashboards:

Fava is maintained by a community. When Beancount updates, Fava gets fixed. When browsers change, Fava adapts. You do nothing.

Custom code is YOUR problem. Plotly releases breaking changes? You fix it. Client wants new KPIs? You code it. Notebook breaks on Python 3.13? You debug it.

When is custom worth it?

You have repeated use cases (10+ FIRE clients = custom dashboard pays for itself)
Clients pay a premium for specialized insights (I charge 30% more for “FIRE Planning Plus”)
The gap between client needs and Fava’s features is genuinely large (not just “I want the bar chart in a different color”)

When Fava is enough:

Standard income/expense tracking (90% of use cases)
Net worth monitoring (built-in charts are beautiful)
Budget vs. actual comparisons (Fava does this well)

The Future: Fava for Clients, Custom for Insights

My current approach: Two interfaces, one truth.

Client-facing: I give clients Fava access to see their transactions and standard reports (they love it—feels professional)
Analysis layer: My custom Jupyter dashboards for FIRE scenario modeling, tax optimization, withdrawal strategies

Both read the exact same ledger.beancount file. I never duplicate data. The plain text is the source of truth, and I can build whatever presentation layer serves the current need.

What About Fava-Dashboards Extension?

Fair question—I should mention fava-dashboards which lets you build custom dashboards INSIDE Fava using Apache ECharts. For many custom visualization needs, this is the sweet spot: more flexibility than default Fava, less maintenance than fully custom code.

I use it for simpler custom charts. But when I need programmatic scenario modeling (running Monte Carlo simulations on retirement success rates), I drop to Python.

Share Your Custom Dashboard Stories

Anyone else building custom visualization layers on top of Beancount? I’d love to hear:

What tools are you using? (D3.js? Tableau? PowerBI exports?)
What use cases pushed you beyond Fava?
How do you handle maintenance and version control?
Any regrets or “I should’ve just stuck with Fava” stories?

The beauty of plain text accounting is infinite flexibility. But with great power comes great… maintenance responsibility.

My stack: Beancount 2.3.6, Fava 1.28, Python 3.12, Jupyter, Plotly, pandas
Clients: 12 active FIRE planning clients, $2.1M average portfolio size
Custom dashboard ROI: ~40 hours to build, saves ~2 hours per client meeting (pays for itself after 5-6 client sessions)

bookkeeper_bob · March 29, 2026, 1:47am

Fred, this is a great write-up, but I gotta be honest: I tried pitching custom dashboards to my small business clients and got zero traction.

The Client Reality Check

When I showed my restaurant owner client a beautiful custom dashboard with food cost trends, labor percentages by shift, and inventory turnover rates… his response was: “Can I pay my bills this month?”

That’s it. That’s what he actually wanted to know.

Most small businesses (at least the ones I serve in Austin) don’t want fancy scenario modeling or interactive charts. They want three questions answered:

Do I have enough cash to make payroll Friday?
Did we make or lose money last month? (and why?)
What do I owe the IRS?

For 80% of my clients, Fava’s standard reports are already overwhelming. They don’t log into Fava weekly. They wait for me to send them monthly PDFs (which I generate from Fava, but still).

Where Custom Dashboards Actually Make Sense

That said, I do have a few clients where custom viz would be game-changing:

10-location restaurant chain: Needs consolidated P&L across locations, labor cost comparison, food waste trends per location. Fava can’t do multi-entity rollups elegantly.

Nonprofit with 8 grants: Different funders want different reporting formats. Having a custom dashboard that filters by grant and shows restricted fund usage would save hours every quarter.

Multi-property real estate investor: 6 rental properties, needs occupancy rates, maintenance costs per property, rent vs. mortgage tracking. Fava works, but a custom dashboard would be cleaner.

But these are outliers. My typical client (solo cafe, 2-person consulting firm, small retail shop) just needs clean books and basic reports.

The Pricing Question Nobody Talks About

How do you charge for custom dashboard work?

One-time build fee? What if it breaks when Plotly updates?
Monthly maintenance retainer? Clients balk at “paying for something that was already built”
Premium service tier? (like your “FIRE Planning Plus”)

I’m genuinely curious because I have 2-3 clients where I could build custom dashboards, but I haven’t figured out the business model that doesn’t make me a permanent code maintenance person.

My current approach: Stick to Fava for 95% of clients, and for the one restaurant chain that needs multi-location reporting, I export bean-query output to Google Sheets and build pivot tables. It’s not sexy, but it works and they understand how to use it.

accountant_alice · March 29, 2026, 1:48am

Fred, excellent breakdown of the technical stack. Bob, you’re absolutely right about client expectations being simpler than we think.

From a CPA perspective, let me add the professional compliance angle that often gets overlooked when we talk about custom dashboards.

The Audit Trail Challenge

Custom dashboards are powerful—but they can also create liability exposure if not implemented carefully.

Here’s what I mean: When a client makes a business decision based on a custom KPI dashboard you built, and that decision goes sideways, they might come back and ask:

“How was that calculation performed?”
“What assumptions were built into the projection?”
“Can you prove the data was accurate on the date I made the decision?”

With commercial accounting software, you can point to vendor documentation and industry-standard reports. With custom code, you own the entire calculation chain.

Best Practices for Custom Dashboard Compliance

If you’re building custom visualizations for clients (especially as a CPA or bookkeeper), here’s what I recommend:

1. Version control everything

Your Beancount ledger in Git (you’re already doing this)
The Python scripts/Jupyter notebooks that generate dashboards (also in Git)
Document WHICH version of the script generated WHICH report for WHICH client decision

2. Document assumptions
Every custom calculation should have inline comments explaining:

Why you chose this formula
What edge cases it handles (or doesn’t)
Any simplifying assumptions (e.g., “assumes constant tax brackets”)

3. Test your calculations
If you’re calculating something mission-critical (tax projections, FIRE withdrawal rates), write automated tests. Yes, even for Jupyter notebooks—use pytest to validate your bean-query outputs against known-good examples.

The Nonprofit Use Case: Where Custom Is Necessary

Bob mentioned nonprofits with multiple grants—that’s actually where I see custom dashboards becoming mission-critical rather than “nice to have.”

Why nonprofits NEED custom reporting:

Different funders demand different report formats (IRS Form 990, foundation-specific templates, GAAP vs. cash-basis)
Restricted vs. unrestricted fund tracking (Fava can’t easily filter by fund and display separately)
Functional expense allocation by program (ASC 958-720 compliance requires this)

I have a nonprofit client with 12 different grants, each with unique reporting requirements. Fava handles the accounting beautifully, but the custom dashboard I built (using bean-query + Python + Pandas) saves them 80+ hours per year in manual report assembly.

How I charge for it:

Initial build: $3,500 (one-time)
Annual maintenance retainer: $800/year (covers updates when funder requirements change)
Additional customization: $150/hour

The client pays it happily because the alternative is hiring a second part-time accountant to manually compile reports.

IRS Compliance and Custom Reporting

Tax season reminder: If you’re using custom dashboards to generate tax reports (Schedule C, depreciation schedules, investment income), make absolutely sure:

Your calculations match IRS publications (link them in comments!)
You can regenerate the EXACT same report from historical ledger state
You have a paper trail showing how AI/automation was verified by a human

The IRS doesn’t care if your AI categorized transactions—you signed the return, you are liable for accuracy.

When Fava + Git = “Good Enough” Compliance

For 80% of use cases (Bob’s point), Fava’s built-in reports + Git version control of your ledger already provide excellent audit trails:

Fava generates timestamped reports
Git commits show what data existed when
bean-check ensures your ledger is valid

You don’t need custom dashboards for compliance. But if you build them, treat them as seriously as you’d treat any professional work product.

My stack: Beancount 2.3.6, Fava, Python 3.11, Pandas, pytest for validation, Git for everything
Clients using custom dashboards: 4 nonprofits, 2 multi-entity businesses
Most common request: “Can you make this report look exactly like what the funder template requires?” (Answer: Yes, with Python + Jinja2 templating)

helpful_veteran · March 29, 2026, 1:49am

This is a fantastic discussion! Fred’s enthusiasm for custom dashboards, Bob’s reality check, and Alice’s compliance wisdom—this is why I love this community.

Let me share my cautionary tale as someone who went down the custom dashboard rabbit hole and (mostly) came back out alive.

My “I Need Custom Everything!” Phase

When I first got comfortable with Beancount about 3 years ago, I had the same realization Fred described: “Plain text = infinite possibilities!”

I got excited and built:

Custom rental property dashboard (cash flow per property, occupancy rates, maintenance trends)
Investment performance tracker (better than Fava’s charts, I thought)
Tax bracket optimizer (predicted which accounts to withdraw from)

Time invested: Probably 60+ hours over 3 months
Ongoing maintenance: 2-3 hours every time Beancount or Python updated
Client usage: Moderate (they preferred the pretty charts to Fava’s default views)

The Moment I Realized I’d Made a Mistake

About 6 months in, Fava released a feature update that added interactive charts with drill-down capabilities. Suddenly, my “custom investment tracker” wasn’t special anymore—Fava did 90% of what I’d built, and it updated automatically with the community.

I looked at my custom code and thought: “Am I really going to maintain this forever?”

The answer was no. I archived the project and went back to Fava for that use case.

The One Custom Dashboard I Kept (And Why)

I did keep one custom tool: Multi-tenant bookkeeping dashboard.

I track finances for myself + 3 family members using separate Beancount ledgers. Fava can’t show me “all four ledgers in one consolidated view” or answer questions like:

What’s the combined net worth across all accounts?
Who has upcoming tax payment deadlines this quarter?
Which family member needs help with their budget this month?

For this, I built a Python script that:

Reads all four ledger.beancount files
Runs bean-query against each one
Outputs a simple HTML dashboard (nothing fancy, just tables)

Why this survived:

Fava literally can’t do cross-ledger analytics (it’s designed for one ledger at a time)
The use case is permanent (I’m not going to consolidate four separate people’s finances)
The code is simple (~200 lines) and rarely breaks

My Advice: Exhaust Fava-Dashboards First

Before you write a single line of custom Python, try the fava-dashboards extension that Fred mentioned.

Seriously, this extension is powerful. You can:

Build custom charts using Apache ECharts (interactive, beautiful)
Write dashboards in TypeScript/JavaScript (or YAML for simpler cases)
Deploy them INSIDE Fava (clients see everything in one interface)

When fava-dashboards is enough:

You need custom chart types (heatmaps, Sankey diagrams, etc.)
You want industry-specific KPIs (nonprofit fund tracking, restaurant CoGS trends)
You’re okay with JavaScript/TypeScript instead of Python

When you need fully custom (Python/Jupyter):

You’re doing complex modeling (Monte Carlo simulations, tax optimization scenarios)
You need to integrate non-Beancount data (pulling stock prices from APIs, currency conversions)
You want programmatic automation (generate reports on schedule, email to clients)

The “Share Your Code” Plea

If you DO build custom dashboards, please share them with the community!

GitHub gists, blog posts, even just posting the script in this forum—don’t let your hard work die on your hard drive.

I’ve learned so much from other people’s custom tools:

Someone’s nonprofit grant tracking script inspired my rental property tracker
Another person’s tax bracket optimizer taught me how to use bean-query more effectively
A simple CSV export script saved me hours of manual work

The Beancount community is built on sharing. Even if your code is “messy” or “not production-ready,” it might help someone else solve their problem.

Summary: Start Simple, Customize Only When Necessary

My recommendation for anyone considering custom dashboards:

Use Fava for 6+ months before deciding it’s not enough. Learn its features deeply.
Try fava-dashboards extension if you need custom charts or KPIs.
Build custom tools only when:
- The gap is genuinely large (not just “I want a different color scheme”)
- You have repeated use cases (10+ clients, or permanent personal need)
- You’re comfortable maintaining code long-term
Share what you build! Help the next person avoid reinventing the wheel.

Alice’s compliance points are spot-on, and Bob’s pricing question is critical. If you can’t answer “Who pays for maintenance when this breaks?”—don’t build it.

What I learned the hard way:

Fava improves faster than I can build custom tools
Maintenance burden accumulates silently (broken dependencies, API changes)
Clients often don’t use “advanced features” as much as you think they will

What I’d do differently:

Wait longer before building custom (exhaust Fava + fava-dashboards first)
Build simpler, more focused tools (not “one dashboard to rule them all”)
Write tests from day one (Alice is 100% right about this)

Great thread, Fred! Looking forward to seeing what others have built.