CronBooks

Problem

A small business either hands its books to someone it cannot see into, or keeps them in tools that record transactions without ever enforcing double-entry correctness — so errors surface at close instead of at entry.

Approach

Building an Elixir/Phoenix application on a strict double-entry ledger: money is modelled as a typed currency value through a composite Ecto type rather than a float, tenants are isolated by PostgreSQL row-level security with a separate admin repo for the few cross-tenant reads, imports and reconciliation run as durable Oban jobs, and credentials are encrypted at rest.

Role

Solo founder and engineer — product, architecture, and implementation.

Stack

• Elixir
• Phoenix
• LiveView
• PostgreSQL
• Row-Level Security
• Oban
• ex_money
• Cloak

Outcome

• — Double-entry correctness is enforced in the ledger itself, not reconstructed in reports
• — Money is a typed currency value end to end — no floating-point rounding in the books
• — Tenant isolation is enforced by row-level security and re-proved by an isolation test in every context module
• — Pre-launch: engineering milestones only — no adoption or usage claims until it ships