PaySahbi — a payments engine, from zero, in the open

This is what zero to production looks like while it is still happening, which makes it more useful evidence than a finished thing where the decisions have been forgotten.

The architecture was written down before the code. The repository carries an engine design document covering tenancy, auth, tables, state machines, flows, ledger rules, events, jobs and the scale plan — and the rule is that the document changes before the code does. That is the opposite of how most side projects go, and it is the habit that makes a system survivable by somebody other than its author.

Some decisions worth stating plainly, because each closed off a tempting wrong turn:

A modular monolith, not microservices. An engine API and a worker, plus two separate deployables where the boundary is real. Splitting early buys distributed debugging and nothing else at this size.

TypeScript, with Go only later — and only for an isolated service, once there is a measured need rather than a predicted one.

The products eat their own API. PaySahbi's own console and mobile app call the public Engine API with first-party keys. No private shortcuts: if something is missing, it gets added to the public API, which means the API is proven by the people who built it before anyone else depends on it.

Schema-first. TypeBox schemas generate the OpenAPI 3.1 spec, so the documentation cannot drift from the implementation. Tests are Vitest with property-based checks and Testcontainers against a real database, because money code deserves more than a few happy-path assertions.