01 — Problem
Building a financial application that can grow
This SaaS project for small businesses brings together financial tracking, statement imports, invoices, alerts and reports. Development began with a shared foundation: a modular architecture, a dashboard shell and automated quality checks. Business domains were then added incrementally.
02 — Constraints
Adding features on a shared foundation
Finance, imports, invoices, alerts and reports need consistent data conventions. The architecture must support incremental development, with quality checks on every release.
03 — Approach
Separating domains and automating checks
Front-endA dashboard for viewing financial data and accessing each business domain.
Back-endA modular monolith with separate routes, services and data access for each domain.
DatabaseA shared data model, consistent from one domain to the next.
- Modular monolith organised by business domain
- Dashboard shell and a versioned REST API (/api/v1)
- Shared data model: UUID identifiers, UTC timestamps, reversible migrations
- Required CI checks: lint, strict typing and tests
04 — Result
Seven domains integrated into the application
The project is still in progress. The foundation and the domains listed below are implemented, each with its own routes, service and data access.
- 42 API routes across seven business domains: authentication, finance, CSV/XLSX imports, invoices, alerts, reports, search
- 5 schema migrations, each one reversible
- 87 automated tests: 56 on the API, 24 front-end unit tests, 7 end-to-end journeys
- Minimum coverage enforced in CI: 90% on the API, 80% on the front end
Source access
On request, I can provide read-only repository access or walk you through the architecture, code and technical decisions behind this project.
Request repository access