Back to projects

Finance Tools

SlateLedger

Personal debt and payment records need conservative handling because unclear states can distort balances, reminders, and decisions.

Abstract ledger interface with record rows, payment timeline, validation states, and privacy panels.

Role

Product engineering, correctness modeling, and privacy-aware workflow design.

Engineering Focus

.NET API foundations, Angular app shell, PostgreSQL-backed records, calculated balances, cookie auth, and export workflows.

Public Scope

Public overview of personal ledger workflows without private financial details.

Correctness foundation

Project Foundation

Public-safe case study focused on a self-hosted household ledger foundation with conservative balance math, authenticated records, and privacy-aware exports.

Evidence Signals

  • Documented entities and APIs center on people, transactions, dashboard summaries, and CSV export.
  • Balances are calculated from transaction rows, preserving explainable record state instead of relying on a stored balance.
  • Authentication, backup/restore, health readiness, and Docker/Unraid deployment notes exist as product foundations without exposing private deployment details.

Engineering Highlights

  • People and transaction APIs keep balances calculated from transaction history rather than stored as a separate balance column.
  • Single-admin cookie authentication, health readiness, and PostgreSQL-backed persistence are documented foundation pieces.
  • CSV export behavior is framed around explicit escaping, Excel compatibility, and avoiding admin credential exposure.

Portfolio Proof Points

  • Calculated balances
  • Authenticated records
  • Privacy-aware exports

SlateLedger is a self-hosted household ledger foundation for debt, payment, and record tracking where people, transactions, balances, and exports need to stay understandable.

Problem Shape

Personal debt and payment records need conservative handling because small mistakes can distort balances, summaries, exports, and decisions. The product direction focuses on making transaction behavior explicit instead of hiding correctness behind unclear or duplicated state.

Product Direction

  • Keep people, transactions, balances, summaries, and exports understandable.
  • Calculate balances from transaction history instead of storing a separate balance value.
  • Protect record access behind the documented authentication foundation.
  • Keep frontend workflows aligned with same-origin API assumptions where applicable.
  • Prefer narrow, explainable rules over broad automation.
  • Keep privacy boundaries central to how the product is described.

Engineering Notes

The strongest engineering thread is correctness. The documented foundation includes a .NET API, Angular app shell, PostgreSQL persistence, health readiness, cookie-based authentication, people and transaction APIs, dashboard summaries, and CSV exports. The useful portfolio signal is the way the product keeps balances explainable by deriving them from transaction rows.

The data model direction is intentionally conservative. People can be archived, transaction history drives balances, currencies stay separate, and exports are described with explicit CSV handling. That makes the case study about reliability and privacy-aware records, not broad financial automation.

Evidence Signals

  • The stack foundation is documented as ASP.NET Core, Angular, PostgreSQL, and Docker/Unraid-friendly deployment support.
  • Authenticated people and transaction APIs are documented, with archived-record restrictions and calculated balances.
  • Dashboard summaries group totals without currency conversion.
  • CSV exports are documented with escaping, compatibility, and no admin credential export.
  • Backup/restore and health readiness notes support the operational foundation without publishing private deployment details.

Public Boundary

This page focuses on product direction and correctness concerns. Private app links, private financial data, private user data, infrastructure details, credentials, logs, private environment values, and live deployment details stay out of view.

Public case study only. Private operations, credentials, logs, dashboards, live app links, real screenshots, and infrastructure details stay out of view.