Financial Control Center

A bank balance does not tell you what you can spend: it ignores commitments, debt, reserved savings and planned transactions. The product turns those rules into an honest financial picture.

A personal project: it started as a way to solve a problem of my own, and I designed and built it from scratch. It is still in development. The repository contains a working application, demo data, architecture documentation and financial-invariant tests against real PostgreSQL.

Build a control center that explains real available money, records operations without rewriting history and lets the domain evolve incrementally.

• Defined the product, domain language, visual experience and full-stack architecture.
• Modeled the domain in Prisma (23 models and 17 enums), documenting which constraints belong in the database and which belong in business logic.
• Implemented authentication, persistence, use cases, responsive UI, demo data and automated tests.

• Next.js 16 with Server Components and Server Actions; PostgreSQL is the source of truth and Prisma is the persistence layer.
• Better Auth shares the domain User and renames its Account model to avoid colliding with a financial account.
• Multi-entity writes run in transactions; Zod validates rules PostgreSQL cannot express.
• 23 ADRs record decisions around domain, security, authentication, state, theming and testing.

• Implemented: accounts, transactions, credit and installments, planning, budgets, savings, loans, reconciliation, rules, overview and analysis.
• Implemented: quick entry, light/dark/system themes, deterministic demo data and per-user data isolation.
• In development: public deployment and refinement of complete flows with real-world data.
• Planned: natural-language transaction entry as a layer over validated use cases, never as direct database writes.

• Distinguishing balance, available money, debt, spending, savings and reimbursements without duplicating sources of truth.
• Keeping an auditable history: transactions are voided instead of deleted and time-sensitive values are derived on read.
• Prioritizing domain correctness over premature abstractions; V1 adds neither a generic repository layer nor global state.

• Domain modeling and invariants shape the product more than any isolated screen.
• Testing financial rules against real PostgreSQL catches failures a mock cannot represent.
• ADRs make the engineering process visible and let decisions be revisited as the product grows.