Summary

Fidelis Wealth Monitor started with a personal need: I wanted a clearer view of my assets, liabilities, and net worth without maintaining another collection of disconnected spreadsheets.

The first version became a Progressive Web App (PWA) with a dashboard, historical snapshots, reports, read-only accountant access, and offline support.

The most useful lessons were not about adding features. They were about keeping the data model understandable, reducing friction when updating information, and deciding which capabilities should remain simple.

Context

Personal finances are often scattered across different places: bank accounts, investment statements, properties, vehicles, loans, and documents prepared for an accountant.

None of those sources is especially difficult to understand on its own. The friction comes from trying to see them together.

I wanted a simple way to answer a few recurring questions:

  • What is my current net worth?
  • How has it changed over time?
  • Where are my assets concentrated?
  • What information will my accountant need?
  • Can I update the data without turning it into another administrative task?

That became the starting point for Fidelis Wealth Monitor.

What I built

The application tracks assets and liabilities across a small set of categories:

  • Bank accounts
  • Investments
  • Real estate
  • Vehicles
  • Mortgages
  • Loans
  • Credit cards
  • Personal debt

The dashboard provides a net worth summary, historical trends, and an overview by category. Reports can be exported for monitoring and accounting purposes.

The application also supports read-only accountant access. That felt more useful than sending spreadsheets back and forth whenever updated information was needed.

A simple data model

The data model is intentionally straightforward:

User
|-- WealthProfile
|-- Asset
|   |-- BankAccount
|   |-- InvestmentAccount
|   |-- RealEstateProperty
|   `-- Vehicle
|-- Liability
|   |-- Mortgage
|   |-- AutoLoan
|   |-- PersonalDebt
|   `-- CreditCard
|-- AssetSnapshot
|-- LiabilitySnapshot
`-- AccountantAccess

One of the most important decisions was to create snapshots whenever an asset or liability changes.

Snapshots make it possible to preserve history without asking the user to maintain a separate timeline manually. They also provide the foundation for trend charts and year-over-year comparisons.

This was a useful reminder: sometimes a small data-model decision has more impact than a visible feature.

Why a PWA

I wanted the application to work well on both desktop and mobile without starting with separate native applications.

A PWA was a practical middle ground:

  • It can be installed from the browser.
  • The dashboard can remain available offline.
  • Recent data can be stored locally.
  • Changes made offline can be queued and synchronized later.

The architecture is relatively small:

Service Worker
|-- Cache static assets
|-- Use the network for APIs when available
`-- Provide an offline fallback

IndexedDB
|-- Store recent assets and liabilities
|-- Cache dashboard data
`-- Queue pending changes

Sync Queue
|-- Save changes while offline
|-- Retry when the connection returns
`-- Resolve conflicts with a simple last-write-wins rule

Not every feature belongs offline. AI-assisted document processing and account sharing still require a server connection. That tradeoff keeps the offline mode useful without making the synchronization layer unnecessarily complex.

Reducing manual updates with AI

Updating financial information manually is repetitive. To reduce that friction, I experimented with importing account statements and extracting structured information from them.

The flow is simple:

Upload a statement
    |
Extract relevant data
    |
Show a preview
    |
Choose what to save
    |
Create or update assets and snapshots

The preview step matters. Financial data should not be silently accepted just because an automated process extracted it. The user still needs a chance to verify what will be stored.

Unexpected challenges

A CSS rule hid contextual actions

Some card menus were being clipped because a parent container used:

.main-content {
  overflow: hidden;
}

Changing the parent overflow behavior and moving scrolling responsibility to an inner container fixed the issue.

The lesson was simple: layout bugs often come from container behavior rather than the component that appears broken.

Decisions made

Use a familiar stack

I used technologies that were already familiar from earlier work:

Backend:        Django + PostgreSQL
Frontend:       HTMX + Alpine.js + Tailwind CSS
Visualization:  Chart.js
Reports:        ReportLab + openpyxl
Storage:        Cloudflare R2
Deployment:     Railway with Docker
Offline:        Service Worker + IndexedDB

The goal was not to experiment with every layer at once. Reusing a known stack made it easier to spend time on the product decisions that mattered.

Prefer incremental complexity

Some ideas are deliberately postponed:

  • Background synchronization improvements
  • Push notifications
  • Voice-assisted data entry
  • More detailed analytics
  • Forecasting
  • Stronger local-data protection

Each one may be useful. None of them needs to exist before the core workflow proves itself valuable.

What I learned

Start with the questions the product should answer

The dashboard became clearer once I focused on a small set of recurring questions instead of a long list of possible features.

Historical data is worth designing early

Snapshots were inexpensive to add at the beginning and difficult to reconstruct later. For monitoring products, history is not an extra feature. It is part of the foundation.

Offline support needs boundaries

Making every capability work offline would add a lot of complexity. A smaller offline mode is more realistic: view recent information, queue changes, and synchronize when a connection returns.

AI is most useful when it removes repetition

The statement-import experiment was valuable because it reduced manual input. The interesting part was not adding AI as a label. It was making a tedious workflow easier.

Future work

The next iterations are less about adding a large number of features and more about observing how the application behaves in regular use.

The open questions are practical:

  • Which updates are still tedious?
  • Which reports are actually useful?
  • Where does offline mode create confusion?
  • Which data should receive stronger local protection?
  • Which automated imports save time without reducing trust?

Those answers should shape the next version.

Closing reflection

Fidelis Wealth Monitor began as a tool I wanted for myself.

That made the first validation unusually direct: I became the first user. It also made it harder to hide behind feature lists. If updating the data felt cumbersome or a report was not useful, I encountered the problem myself.

Building for your own use does not guarantee that a product will work for anyone else. But it can be a good way to discover the real shape of a problem before trying to scale the solution.

Explore Fidelis Wealth Monitor.

View the GitHub repository.

- Diego Cervera