Incoming data remains separate from committed state.
Make silent drift visible.
Make unsafe writes impossible.
I designed, built, and operate a financial-operations platform for a private operator. It reconciles an externally maintained spreadsheet against a canonical ledger, holds money paths behind explicit invariants and append-only records, and stops when evidence is ambiguous instead of manufacturing a confident answer.
Operational scale, without exposing the operation.
These are conservative, source-traced floors. The operator, domain, internal counts, product screens, source code, and production configuration remain private.
A wrong number can look healthier than a crashed system.
The operator's spreadsheet remained part of daily work. Replacing it outright would have broken adoption; trusting it blindly would have allowed two sources of truth to drift. The platform therefore treats reconciliation as a continuous operational control, not a month-end cleanup task.
The governing ruleStage, validate, reconcile, approve, and commit atomically. If the system cannot prove what a financial write means, it does not perform it.
Every write earns its way into the ledger.
Malformed, duplicate, or unmapped rows fail closed.
External records are compared with computed ledger truth.
Risk and amount determine the human gate.
Atomic writes land with evidence; ambiguity rolls back.
Correctness comes from constraints, not confidence.
Compare continuously, classify the residual.
Independent comparison streams surface row gaps and balance drift without allowing one malformed section to suppress the rest. Alerts explain how much of a mismatch the unmatched evidence accounts for.
Preview and commit use one detector.
The dry run and write path share the same validation and deduplication decisions, so operators do not approve one interpretation and commit another.
One canonical calculation, checked at runtime.
All balance surfaces reuse the same primitive. A one-cent invariant stops divergent formulas before a plausible but wrong number propagates.
Corrections are new facts, never edited history.
Money-changing actions retain actor and before/after context. Adjustments are typed counter-entries, preserving what happened and why.
The largest convenience remains deliberately gated.
Bulk effects are staged as reviewable differences and stay disabled until a fresh preview is approved. In financial software, choosing not to write can be the most important feature.
A sole-engineer system still needs an operations team.
Monitored work
Scheduled jobs record health and failure state; monitoring failures are isolated from the work being monitored.
Recoverable state
Encrypted backups, checksum verification, and restore practice make recovery an exercised path rather than a document.
Visible stop conditions
Stale evidence, drift, failed sends, and uncertain mappings route to review instead of silently continuing.
The proof is strong because its limits are explicit.
| Area | Public status | Boundary |
|---|---|---|
| Operational scale | Verified floors | ~$56M gross ledgered volume; 24,000+ transactions |
| System breadth | Verified floors | 200+ endpoints; 40+ database tables |
| Engineering decisions | High-level only | Reconciliation, invariants, append-only records, approvals, operations |
| Product material | Withheld | No photos, screenshots, demo, product UI, or repository link |
| Implementation and operation | Private | No source, schemas, deployment details, credentials, operator identity, or private counts |
Reliability is not the absence of mistakes. It is the ability to detect drift, preserve the evidence, stop unsafe effects, and turn each discovered gap into a permanent system constraint.