work / 03
A SaaS platform, from sign-up to billing.
Most SaaS builds look finished in a demo and stall right after it: accounts, roles, tenant isolation, billing and admin are the unglamorous half — and they are exactly the half that decides whether a product can be sold and run.
the problem
Every feature has to answer the same three questions: who is asking, which tenant do they belong to, and what have they paid for. When those answers are scattered across the codebase, each new feature invents its own version — and the first customer who sees another tenant’s data ends the story.
what we built
A multi-tenant data model with organisations, users and roles; authentication and authorisation enforced on the server; Stripe subscriptions with entitlements checked where the work happens; admin surfaces for the team that runs the platform; and a release pipeline that builds, tests and deploys every commit to AWS — EC2 servers and S3 for assets — with a documented rollback.
the decision that kept it simple
Billing and entitlements live behind one boundary, with an append-only record of what happened. Plans can change, refunds happen, webhooks arrive twice — and there is still one place that answers “what is this account allowed to do, and why”. Everything else in the product asks that place, and nothing reimplements it.
where it stands
Running in production with real users; deploys come from commits instead of checklists, and rolling back is one documented step.