Two foundations. The hard 80% already solved and tested.
Most products die in the plumbing: auth, billing, tenancy, background jobs. I built that plumbing twice, as two separate codebases, each architected for its business model, carrying 10,000+ unit and integration tests between them, so every build starts at your features, not a blank repo. You ship on the one that fits: 3,500+ tests on the user-gated foundation, 6,500+ on the tenant-gated one.
Specification
Two codebases. Pick by the gate, read the spec.
Note — The only architecture decision you make is the gate: does your product charge people, or companies? Everything behind the gate is already built and tested.
Its own codebase: one deployable with folder-based module boundaries, simple to operate and fast to iterate. Everything gates on the individual user: identity, subscription, entitlements, limits.
Its own codebase: modules bounded by project, ready to extract into microservices when scale demands, with no rewrite. Everything gates on the tenant: isolation, seats, roles, invites, audit. It serves individuals too. A solo customer is a tenant of one, and that account grows into a team without a migration.
Every build ships with the client-facing stack.
Backend on the matching foundation, plus its client stack. The bundle differs by which foundation fits.
Section A-A · through a client build
Your features are the only part left to machine.
Hatched — existing material. Both foundations are private codebases; Shopilent, the open-source backend built to the same standard, is not: 4,000+ tests, public on GitHub.
- ✓Full source of your product, foundation included
- ✓Host anywhere, modify freely for your business
- ✓Perpetual license — no ongoing fees to keep running
- —The foundation IP — it powers every build
- —No redistributing the foundation source
- —No building new products on top of it
Build it once.
Scale on it.
Tell me what you're building, or what your AI-built MVP is struggling with. I reply within 24 hours with an honest read.