AuthSales, one foundation for several systems
My personal project: a commercial SaaS platform that also serves as the foundation for systems in other domains, such as sales, healthcare and ERP.
- TypeScript
- Fastify
- React
- PostgreSQL
- Redis
- TypeORM
Sales· freelance
- Customers
- Products
- Quotes
Healthcare· study
- Clinical
- Status flows
ERP
- Sales
- Purchasing
- Stock
- Tax
AuthSales foundationbackend, frontend and type packages
- Authentication
- Permissions and scope
- Audit and outbox
- CRUD and screens
- Themes and i18n
- PDF and e-mail
The problem
Building a multi-company platform alone that could be the foundation for other systems, without falling into any of these three traps.
Half-done writes
An order with no audit entry, and no other system heard about it.
Another account's data
A user from Account A looking at an order from Account B.
Copied code
A fix made in one system never reaches the copies.
How it works
Deny-by-default scope
A record from another account answers the same as one that does not exist.
All or nothing
The write, its audit entry, idempotency receipt and events share one transaction.
A foundation in packages
Backend, frontend and types are published. Each system only writes its own domain.
Four kinds of time
Declared in the schema, because a due date is not an instant.
Done means evidence
API, permission, persistence and browser, with executable evidence.
Extensions and agents
A declarative, versioned SDK, and local AI agents whose diffs the system validates.
Outcome
Over a hundred services moved without changing a single public signature, and every new system starts with authentication, permissions, audit and themes.
- A transactional outbox in PostgreSQL: the write, the audit entry and the events in one transaction
- A due date is not an instant: four kinds of time in PostgreSQL and TypeScript