Case Study

Sovereign Ledger

A comprehensive financial management system built for a health-worker cooperative in Garut, Indonesia — deployed on-premise and in active use.

🔒 NDA · KPRI Warga Kesehatan
Laravel 13 Livewire 4 Alpine.js PostgreSQL Tailwind CSS Docker Full-Stack Solo Build

The Problem

KPRI Warga Kesehatan Kabupaten Garut — a health-worker cooperative in Garut, Indonesia — needed a complete financial management system. They had been running on Excel spreadsheets for years, with their full transaction history locked in legacy files. Off-the-shelf solutions were either too expensive or couldn't handle the cooperative-specific business logic (compulsory savings, social funds, multi-type loans).

The core challenge: build and deploy a production-grade financial system as a solo developer — double-entry accounting, role-based access for five user roles, automated monthly batch processing, professional reporting, and a full data migration from their existing Excel records.

The Architecture

graph TB A[Docker: PHP-FPM + Nginx] --> B[Laravel 13 + Livewire 4] B --> C[PostgreSQL] B --> D[Alpine.js Frontend] C --> E[Chart of Accounts] C --> F[Transaction Ledger] C --> G[Loan Management] B --> H[Automated Batch Processing] H --> I[Monthly Savings] H --> J[Social Funds] H --> K[Loan Installments] B --> L[PDF/CSV Reporting] style B fill:#6c5ce7,stroke:#7c6df0,color:#fff style C fill:#00d2ff,stroke:#00b8e6,color:#0a0a0f style A fill:#f7c948,stroke:#e0b830,color:#0a0a0f

Why It's Hard

  • Double-entry accounting from scratch: Every transaction must balance. A full Chart of Accounts hierarchy, audit trails, and period locking. Getting this right as a solo developer — without an accounting background — required deep domain learning.
  • Legacy data migration: The cooperative's complete transaction history lived in Excel files spanning years. Importing, cleaning, and reconciling this into a normalized PostgreSQL schema was a data engineering challenge in itself.
  • Five distinct user roles: Admin, teller, member, auditor, and super-admin — each with different permissions, views, and workflows. Role-based access control had to be airtight for a financial system handling real money.
  • On-premise Docker deployment: The system runs on the cooperative's own hardware — PHP-FPM + Nginx + PostgreSQL in Docker containers, with Supervisor-managed scheduling for automated monthly batch jobs and persistent volume backups.

Key Features Delivered

  • Full Chart of Accounts — hierarchical account structure with double-entry enforcement
  • Automated monthly batch processing — compulsory savings deductions, social fund contributions, and loan installment postings run on schedule
  • Multi-type loan management — with automatic installment scheduling, interest calculation, and repayment tracking
  • Role-based access control — five user roles with granular permissions
  • Professional reporting — PDF reports with KOP letterhead branding, CSV exports, and printable ledgers via Laravel DOMPDF + PhpSpreadsheet
  • Legacy data reconciliation — full import and reconciliation of years of cooperative transaction history from Excel

What I'd Do Differently

  • Add automated testing earlier. Financial software without tests is terrifying. I added PHPUnit tests partway through, but having them from day one — especially for the double-entry balance checks and loan calculations — would have saved debugging time.
  • Use Laravel's built-in features more aggressively. I initially underused Laravel's queuing, notifications, and event system. Refactoring batch processing to use Laravel queues with Supervisor made the system significantly more robust.
  • Design the role-permission system with more granularity. Five roles worked for the initial deployment, but as the cooperative grows, finer-grained permissions would reduce the need for custom overrides per user.
  • Build a dedicated data import pipeline. The legacy Excel migration was done semi-manually. A repeatable ETL pipeline would have made the reconciliation process faster and more auditable.

Key Takeaways

Building a production financial system for a real institution — as a solo developer — teaches you more than any tutorial. Double-entry accounting isn't just a feature, it's a constraint that shapes every design decision. The system is deployed on-premise at the cooperative and used daily. That's a different level of accountability than a side project.
← Back to Projects