SaaS Platforms We Build & Run

Multi-tenant isolation, subscription state, payment reconciliation and real-time order flows are not things you learn from a tutorial and then get right at scale. They are learned by running them — by finding out that a tenant's timezone setting reaches all the way into reporting, that a payment webhook can arrive twice, and that an order edited after dispatch has to reconcile against a printed receipt, a POS ticket and a courier who already left.

Those arrive in a client project as decisions rather than experiments. When we argue that a schema should carry a tenant id from the first migration, or that refunds need an audit trail before they need a screen, it is because the alternative already cost us something.

A studio that only builds is optimised for handover. We cannot hand SuperApp or Supaorder to anyone, so both have to be operable by us at three in the morning — and that changes what gets built. Monitoring and structured logs are part of the definition of done. An upgrade has to roll forward across every tenant without a maintenance window. Configuration lives somewhere a support person can reach without a deploy.

Client projects inherit the bias. What you get is designed for the two years after launch rather than the demo at the end of the project, which is also why every engagement closes with a warranty period and most carry on into a support retainer.

Both platforms have been in production long enough for the shortcuts to come due. Code we wrote in a hurry, we maintain. Abstractions we invented to save a week, we live inside. Nothing teaches restraint like being the team that has to open the file again two years later, and nothing exposes a clever idea faster than a support ticket about it.

That is the whole argument for hiring a studio that also ships products: the incentives point the same way as yours. We are not optimising for the shortest path to a signed handover, because on these two we have never had one.