Why we built the ledger first

Most products start with a screen. PrimeEx started with a rule: no service, worker, or admin action is ever allowed to do wallet.balance -= amount.

That sounds like a small technical preference. It isn't. It's the difference between a balance being a number a screen happens to show and a balance being the sum of a real, provable history and it's the first decision we made, before a single line of frontend code.

The rule

Every financial movement on PrimeEx is expressed as a balanced double-entry transaction: a set of entries whose debits equal its credits, written atomically in one database transaction, and never edited after the fact. A correction isn't a patched number, it's a new, reversing entry. The old entry stays exactly as it was.

That means a balance is never a mutable field somewhere that a bug, a race condition, or a bad migration can silently drift. It's always a projection, rebuildable, at any time, from the entries themselves. If a cached balance and the ledger ever disagreed, the ledger wins, by construction.

What this actually buys you

It's easy to say "double-entry ledger" and move on. The value shows up in the boring cases:

• A duplicate request never becomes a duplicate balance change. Two entries either both exist or neither does, there's no in-between state where a balance was touched but the record of why is missing.
• A dispute has an answer. "Why is my balance what it is" is never "trust us", it's a literal, ordered list of entries, each one immutable.
• A bug is recoverable. If something is ever wrong, the fix is a new entry that corrects it, not a hotfix that edits history and hopes nobody asks what the balance used to be.

None of this is exotic. It's how real banks and payment processors have worked for decades. The unusual part, for a project this early, was refusing to skip it, building and adversarially testing the ledger before there was anything for a customer to look at.

The order mattered

If we'd built the interface first, "add a ledger later" would have meant retrofitting correctness onto code that was never designed for it, finding every place a balance was touched directly and hoping we found all of them. Building it first meant every feature since (transfers, cards, crypto, FX conversions) was written against the ledger from day one, never around it.

That's the whole philosophy behind how PrimeEx gets built: get the part that's expensive to fix later right first, then build the parts people actually see.