Acc. XV · Vitis collectiva — lending and collection ledger, cultivated 2026
Kolekta — multi-tenant lending and collection ledger
Technical founder · Product engineer · 2026 · Independent studio
A multi-tenant lending and collection system for Philippine SMEs covering loan books, amortization schedules, and offline-first field collections.
Vitis collectiva — lending and collection ledger, cultivated 2026
Field notes
The context
Lending and collection for Philippine SMEs typically runs on spreadsheets — amortization computed by hand, collections logged after the fact, and no enforced separation between what a field collector can touch and what an operator can override. Kolekta builds the loan book, the schedule engine, and the field-collection workflow as one system with an append-only ledger underneath.
Cultivation
What I built
- Built the multi-tenant loan-book dashboard with borrower and loan CRUD, and amortization across four payment frequencies (daily, weekly, semi-monthly, monthly) supporting both add-on and diminishing interest methods.
- Built the centavo-denominated integer money engine and penalty accrual logic, with SQL and TypeScript implementations kept in enforced parity for both fixed and percentage penalties.
- Built collection tracking with receipts against an append-only audit ledger, where corrections are reversal entries rather than mutations.
- Built the offline-first field-collector PWA with an IndexedDB outbox and background sync for collectors working without signal.
- Built the operator super-admin panel with payment verification and a tenant state machine (trial → pending_payment → paid → grace → suspended), driven by subscription lifecycle automation on Vercel Cron.
- Wrote 140 unit and property-based tests (Vitest + fast-check) pinning the money and schedule engines, plus Playwright coverage of the payment flow.
Root system
How it works
A single Next.js 16 App Router application on a pnpm workspace, using React 19 islands with RSC for first paint and Server Actions for mutations rather than a separate API layer, aside from cron and contact routes. Supabase Postgres enforces multi-tenancy at the database layer via tenant_id on every table, with RLS gating every read and write. Payment and schedule rows are append-only and corrected by reversal entries, never mutated in place. Vercel Cron drives the tenant state machine's subscription transitions.
Harvest
Outcomes
- Build is complete: 11 migrations, 140/140 tests green, typecheck/lint/build clean, and the payment-flow E2E suite passing.
- Not yet deployed to production and not serving any users — this is a finished build, not a live product.
- Known gap: reversing a payment does not yet reopen the schedule allocations it affected.
- Reviewed with dedicated Opus and Sonnet passes focused on security and PRD compliance before being called done.
Herbarium
The work itself






Enforcing SQL/TypeScript parity on the penalty engine as a tested contract, rather than trusting the two implementations to stay in sync by convention, is what made 140/140 mean something. Append-only ledgers push complexity into reversal logic up front — the unhandled reversal-reopens-allocations case is exactly where that trade surfaces.