Why I built saas-starter
One software architect's opinions on what a new SaaS should look like in month one.
I'm Benoit, a French software developer and architect with more than ten years building and scaling production systems — from early-stage products figuring out their first paying customers to platforms serving millions of users a day.
Across those projects I kept rebuilding the same foundation: authentication, multi-tenancy, billing, transactional email, observability, GDPR scaffolding, async workflows, deployment pipelines. The boring-but-necessary plumbing every SaaS needs in its first month. It always took longer than expected, and the choices made under pressure became the tech debt I'd be paying off for years.
Two goals, equal weight
Ship fast. The faster you get to a real user, the faster you learn what to build next. Every hour spent re-implementing password reset is an hour not spent on the thing that actually differentiates your product.
Ship well. Speed-to-first-deploy is easy to optimise for; speed-at-month-eighteen is what kills products. The architecture you bolt together in week one either supports the team you'll have in year two, or it doesn't. saas-starter picks the patterns I'd want to inherit: hexagonal per domain, end-to-end typed errors, contract-first APIs, observability from the first request, compliance scaffolding from the first signup.
Flexible by design
Every dependency is open source. Every service can run in your own infrastructure with the same compose file the project ships with — or behind a managed equivalent when you'd rather not run it yourself. Nothing locks you into a vendor; nothing forces you to self-host either.
Who this is for
Solo founders and small teams who want to spend their early months on product, not scaffolding — and who care about not regretting their stack choices once they have customers depending on them.