A SaaS platform where a new customer is a new tenant, not a new deploy
The gap between a working demo and a sellable SaaS is almost never the product idea — it is data isolation, onboarding that does not need an engineer in the room, and a config layer that survives changing vendors. This is the build that closes that gap, running in production today as a multi-tenant AI platform.
Your second customer decides whether you have a SaaS or a custom project.
With one customer everything works: you configure by hand, tweak the code, deploy. The second one tells you whether the product scales or every new sale is another project. Data isolation, onboarding without an engineer and per-customer configuration can't be bolted on later without migrating live data — they're decided on day one.
Put in your numbers.
Tenant model
What's isolated, what's shared and who sees what — decided before the first table.
Self-serve onboarding
Customers sign up and connect their own channels without a ticket.
Configuration without code
Brand, pricing, flags and keys in a per-tenant admin panel.
Swappable providers
AI, payments and email behind one interface: changing them is config.
Isolation as structure, not discipline
Each tenant's data, config, and knowledge base is isolated at the schema and query level, not by convention — the class of bug that leaks one customer's data into another's screen becomes hard to write by design.
Self-serve onboarding
A client connects their own number, domain, or account through an in-app flow, not a support ticket to you.
Vendor-agnostic by design
Providers sit behind one interface, so swapping an LLM, a payment processor, or an email vendor is a config change, not a rewrite.
Per-tenant configuration that never touches code
Brand voice, pricing, feature flags, and API keys live in an admin surface — changing how one tenant's instance behaves is a form submission.
Built for a cheap second customer
The expensive part of multi-tenant SaaS is usually the first customer; the second one should be a row in a table, not a new project.
Tick what happens to you today.
Melow: a multi-tenant AI agent platform live in production, where a second clinic is a new tenant with isolated data and its own knowledge base — not a new codebase.
Before you ask
Can I switch AI or payment providers later without a rewrite?
That's designed in from the start — on the reference platform, switching the LLM provider is two environment variables and a restart, because every external provider sits behind one interface instead of being called directly from business logic.
How do you guarantee one tenant can't see another tenant's data?
Isolation happens at the schema and query level, not by convention or a careful WHERE clause — each tenant's data, config, and knowledge base are structurally separated, so it isn't something a future bug can accidentally cross.
Is multi-tenant overkill if I only have one client right now?
If a second client is realistically coming, building isolation in from day one is far cheaper than retrofitting it later — retrofitting means migrating live data under a paying customer. If it's genuinely one client forever, this is more architecture than you need.