Twelve weeks from zero to deploying a multi-tenant SaaS — a system where each client operates in their own environment, with isolated data, inside the same application. It wasn't luck, and it wasn't without stumbles. Here are the choices that sped things up and the mistakes we avoided.
The 3 choices that sped things up
- Multi-tenant with database isolation, from day one. Deciding early how each client's data stays separate avoids rewriting half the system later. We treated isolation as a foundation, not a future tweak.
- Authentication and permissions solved before the first screen. Who sees what is the backbone of the product. Leaving it for the end means patching every page later. Solved at the base, everything else inherits it for free.
- A single data model, built to grow. Instead of a table per client, a structure that scales with a tenant filter. Less repeated code, fewer places for bugs to hide.
The 5 mistakes we avoided
- Generalizing too early. It's tempting to build for "any case". We built for the real case in front of us, and abstracted only when the second client showed what actually varied.
- A pretty screen with no flow. UX isn't button color — it's the path to the finished task. We mapped the main flow before thinking about aesthetics.
- Postponing the deploy. Going live early, even incomplete, exposes the real production problems while it's still cheap to change.
- Ignoring the empty state. The first screen the client sees is the empty one, with no data at all. Handling it well changes the entire first impression.
- Thinking performance is a later problem. Some database decisions are expensive to reverse. Thinking about volume early avoids the most painful rework.
The lesson that stuck
Speed doesn't come from skipping steps. It comes from getting their order right.
Twelve weeks worked because what was foundation — data, access, flow — was solved first. What was a tweak stayed a tweak. Inverting that order is what turns a three-month project into a one-year one.