Why is provisioning harder on a single-tenant architecture?

Because a new client isn't a row added to an existing database. It's a new Postgres project, with its own storage and edge functions. All of it has to be created, set up and linked to the shared app code before that client can log in.

Can a client instance be provisioned by hand safely?

Yes. Like any infrastructure, it can be done right by hand. But hand work doesn't scale past a small number of clients. The more steps a person repeats for each new instance, the more chances one instance has to end up slightly different.

What does a new SalesCrew client instance start with?

Its own Supabase project in the region the client chooses: a Postgres database, storage and edge functions shared with nobody. Row-level security and the three-axis access model apply from the first login. The client's data can leave at any time as a full Postgres dump plus CSV.

Provisioning a client instance in one click

On a single-tenant design, a new client is a new database, not a new row. Doing that well takes real engineering.

app.salescrew.io/today

The short answer

On a shared, multi-tenant database, adding a customer means adding a row. On SalesCrew's single-tenant design, it means a whole new Supabase project: its own Postgres database, storage and edge functions.
That's the work behind the isolation and full export a single-tenant design gives you. Setting up each instance becomes an engineering problem of its own, and it pays to automate it.
Each SalesCrew client instance is its own Supabase project in the region the client picks, so data residency is set when the instance is created.
SalesCrew provisions an instance as a single triggered workflow, a fleet heartbeat watches every instance from one place, and a snapshot seeds the new instance's setup.

Why 'add a client' means something different here

On a shared, multi-tenant database, adding a customer is mostly a data task. You create a customer ID and some default rows, and you're done in seconds. Its servers already exist and already run every other customer. A single-tenant design changes what that task is. A new client on SalesCrew needs a new Supabase project, with its own Postgres database, storage buckets and edge functions. None of it is shared with any other client's instance.

That's real infrastructure work, not a data insert. It comes with the same choice that gives you isolation, a full database export and a region per client. Any product that wants single-tenant promises and fast onboarding has to treat provisioning as its own engineering problem. The multi-tenant shortcut, "add a row," isn't there.

What actually has to happen to stand up a new instance

Setting up a single-tenant client instance takes several steps, and each one has to finish cleanly. First, you create the database project in the chosen region. Then you apply the current schema and deploy the edge functions the app depends on. Next come the settings for that client: channels, integrations and branding. Last, you link the new instance to the billing, monitoring and access systems the platform runs centrally.

A person can do all of this by hand, checking each step before moving on. That works for a few clients, where someone can repeat the steps with care each time. As the number of instances grows, hand work turns into a bottleneck and a source of drift. Every manual step is a chance for one instance to end up set up slightly differently. Nobody notices until it causes a problem for that one client.

What a client gets once the instance exists

Every SalesCrew client instance is its own Supabase project. Your client picks the region, so data residency is settled at setup, not promised in a contract. Its database, storage and edge functions belong to that instance alone. Credentials and API keys go into Supabase Vault and are never shown again after you enter them.

Access control works the same way from the first login. Row-level security and the three-axis scope model (channel, marketplace profile and area) apply to the UI and to MCP tokens alike. Every action in the app is also an MCP tool, and anything an agent sends waits in one approval queue. Your price doesn't change with headcount. Seats are unlimited on every tier, from $299 a month for Core.

The exit is part of the design. Export is a full Postgres dump plus CSV everywhere. On churn, the instance goes read-only and export stays open. It's deprovisioned after 90 days, as a step a person triggers.

SalesCrew runs provisioning as a single triggered workflow that completes the steps above in one go. A fleet heartbeat watches every instance from one place. Snapshot export and apply sit beside it, so a working instance's stages, cadences, dispositions and agent policy seed a new one.

If you're weighing up a single-tenant product, ask one question directly. Don't stop at how provisioning runs. Ask what a new instance starts with once it exists. An instance that starts empty makes every client a fresh setup project. One that starts from a snapshot of a working setup lets you repeat what already works.

Questions

Why is provisioning harder on a single-tenant architecture?: Because a new client isn't a row added to an existing database. It's a new Postgres project, with its own storage and edge functions. All of it has to be created, set up and linked to the shared app code before that client can log in.
Can a client instance be provisioned by hand safely?: Yes. Like any infrastructure, it can be done right by hand. But hand work doesn't scale past a small number of clients. The more steps a person repeats for each new instance, the more chances one instance has to end up slightly different.
What does a new SalesCrew client instance start with?: Its own Supabase project in the region the client chooses: a Postgres database, storage and edge functions shared with nobody. Row-level security and the three-axis access model apply from the first login. The client's data can leave at any time as a full Postgres dump plus CSV.