Harbor

Personal budgeting is often presented as a simple categorisation exercise. The real work is more mixed: reviewing what happened, planning what is about to happen, reconciling a bank connection, and deciding what deserves attention now.

Harbor is the personal system I am building for that work.

The problem I wanted to solve

I wanted my accounts, transactions, targets, and scheduled movements in one place—but I also wanted the interface to respect the difference between an overview and a workspace. A big financial table can be useful. It should not be the only way into the product.

The initial application already had meaningful domain behaviour: bank synchronisation, recurring transactions, transaction history, targets, and undoable actions. The design problem was how to make that capability easier to read and safer to operate as it grew.

The product bet

The current direction is a dark, focused data canvas with a few clear working modes:

• Overview for orientation and deciding where to look next.
• Plan and Transactions as first-class table workspaces, not disguised dashboard cards.
• Accounts and Insights for the questions that need their own frame.
• A contextual inspector and a lightweight dock instead of a permanent sidebar competing with the financial data.

This is not a visual reskin. It is an information-architecture decision: arrive at an overview, enter a focused workflow, and keep the surrounding context available without keeping every control on screen.

How it evolved

The work has followed the product from data model to interface:

1. Build the financial substrate. Accounts, transactions, targets, scheduled transactions, teams, bank connections, and recovery actions established the durable record.
2. Audit the working experience. The existing pages exposed real issues: large desktop screens still behaved like a narrow column, account and plan workflows carried too much UI at once, and the primary entry point did not always match the task.
3. Redraw the shell around behaviour. The new direction separates orientation from data-entry work, treats the inspector as contextual rather than permanent, and defines a different mobile navigation rather than shrinking the desktop layout.

There is a craft decision beneath that last step: the largest screens were doing too much. Before pushing new visual tokens everywhere, I am breaking them into domain components so the interface can iterate without making the finance logic opaque.

How it is put together

Bank connection ─┐
Scheduled jobs ─┼──→ Laravel domain
Manual actions ─┘     accounts · transactions · targets · plans
                              │
                              ├── queue work for bank sync
                              ├── scheduler for recurring transactions
                              ▼
                       Inertia + React workspaces

The backend owns the financial record and scheduled processes. The frontend is not a detached dashboard; it is the place where that record is reviewed, corrected, planned, and acted on. Keeping the operations close to their domain data matters more here than adding decorative data visualisation.

What I still want to prove

The next test is whether the new shell makes review and planning faster without hiding important detail. I want to capture the flows where someone goes from “what is happening?” to a concrete adjustment, and use those to keep refining the hierarchy.

Screens to add

• The overview and the decision it is designed to support.
• A plan or transaction workspace with the contextual inspector open.
• The bank connection and sync status when something needs attention.
• The mobile navigation, showing the deliberate reduction in destinations.