Aurora
[Product · Aurora Labs]
Multi-company ERP platform. A vertical application platform with the general ledger as its kernel: a multi-company SaaS ERP (schema-per-tenant) with a declarative module generator that emits pre-wired, architecturally validated packages, turning each new module from weeks of fragile plumbing into hours.
Results
- From weeks to hours[Result]Time to ship a new module
- Enforced in CI[Result]Architectural invariants checked on every build
The problem
Custom business software does not scale: every client becomes a fork, every module reinvents the wiring, and quality depends on whichever developer wrote it that day. Building financial-grade software by hand (double-entry integrity, multi-company isolation, fiscal rules per country) is slow and error-prone.
The solution
I designed Aurora as a kernel (the GL treated as an event-log protocol) with a platform SDK of contracts and a deterministic generator (aurora:make-module) that stamps canonical, pre-wired modules. Architectural invariants are enforced as fitness functions in CI: money is always BCMath, company isolation cannot leak, and satellites never touch the ledger directly.
The challenge
Craftsmanship does not scale
- Every client, a fork
- Custom business software tends to branch per client. Every new company or vertical reinvents the same wiring (authentication, multi-company, permissions, reporting), multiplying maintenance cost and the surface for errors.
- Quality that depends on the person
- Without built-in barriers, financial integrity (double entry, exact money without floats, isolation between companies) depends on the developer of the day remembering the rule. Human discipline is not an architectural guarantee.
- Fiscal and regional rigidity
- Hard-coding one country's rules (Guatemala's IVA, ISR and FEL/SAT) blocks expansion to other regions and forces costly rewrites with every regulatory change.
The approach
Kernel + SDK + generator
- The general ledger as protocol
- The kernel is the GL, treated as an event log of two irreducible facts (entries and reconciliations). Every operation with a financial effect is posted; reports are regenerable projections. Satellite modules orbit that core: some post movements and create direct financial consequences, others only emit events and do not post, but none touches the entry lines from the inside; all go through the same protocol.
- Aurora Platform SDK + generator
- A runtime contract SDK and a deterministic generator (aurora:make-module) turn a declarative manifest into a pre-wired package: provider, plugin, permissions, migrations and tests, all emitted by construction. The generator emits the same canonical structure with no human variation.
- Quality built into the line (fitness functions)
- Architectural invariants are checked as architecture tests in CI: money is BCMath, multi-company isolation cannot leak, bulk inserts carry their company, and accounts are resolved by determination instead of by code. A module that breaks a rule does not compile.
The impact
Decreasing marginal cost
- From weeks to hours
- A module that used to take weeks of fragile wiring now starts green and audited from a manifest. As the catalog grows, the marginal cost of the next implementation drops.
- Extensible by country
- Fiscal rules live in strategies and catalogs per country (not in the calculation code), enabling expansion across Latin America without rewriting the engine. A new fiscal format is a new provider, not a fork.
- A reusable platform, not boilerplate
- Aurora is the base on which real SaaS products are born without forking the kernel. It is a vertical application platform (architecture as a product) and not a horizontal app builder.
Technologies
Laravel 13 · Inertia · Vue 3 · TypeScript · Filament 5 · PostgreSQL 16 · Multi-tenancy · Domain-Driven Design · BCMath · Pest · Event-Driven Architecture