Stemwall

Problem

Every new SaaS product re-implements the same foundation: identity, tenancy, API keys, metering, transactional email. Each rebuild is slightly different from the last, so a fix in one product never reaches the others, and the differences are accidental rather than considered.

Solution

Extracted the foundation into versioned packages that own their own D1 schema, with per-package migrations composed into a single ordered plan per application database and guarded against drift. Delivery is sliced rather than big-bang: each slice ships as a release, and the scope it does not cover is written down and tiered rather than left implied. Tests run in two lanes from one shared suite — Bun for pure logic and real workerd for Workers-API behavior — because passing under Bun does not prove behavior on Workers.

Role

Creator, architect, and lead engineer

Technologies

Impact

• Extracted authentication, tenancy, API keys, metering, and transactional email out of individual products into versioned shared packages, so a fix lands once instead of once per product
• Proved the abstraction against a deliberately divergent second consumer whose identity model had been designed independently, rather than against a product built to fit it
• Benchmarked the extraction against mature SaaS chassis and published a tiered accounting of what it deliberately does not yet cover, each gap named with the existing slice it should extend rather than becoming a new one
• Let each package own its D1 schema and migrations, composed into one ordered plan per application database through a shared migration registry
• Ran one shared test suite through two runners — fast pure-logic units under Bun and the full suite inside real workerd — so Workers-API behavior is proven on Workers rather than assumed from a Node-like runtime