Provisioning a client instance in one click

On a shared multi-tenant database, onboarding a new customer is mostly a data operation. A new customer ID, some default rows, done in seconds, because the infrastructure already exists and already runs for every other customer. Single-tenant architecture changes what that operation is. A new client on SalesCrew means a new Supabase project has to exist: its own Postgres database, its own storage buckets, its own edge functions. None of it is shared with any other client's instance.

That is real infrastructure provisioning, not a data insert. It is the direct cost of the architectural choice that also buys isolation, a full-database export and a per-client data-residency choice. A product that wants single-tenant guarantees and fast onboarding has to solve provisioning as its own engineering problem. The multi-tenant shortcut, "add a row", is not available.

Standing up a single-tenant client instance takes several steps, and all of them have to complete correctly. Create the database project in the chosen region. Apply the current schema to it. Deploy the edge functions the application depends on. Configure the deployment-level settings for that client: channels, integrations, branding. Connect the new instance to the billing, monitoring and access-control systems the platform runs centrally. Doing this by hand is possible, and that is what the process looks like before it is automated. A person works through each step, verifies it completed, and moves to the next.

Manual provisioning does not scale gracefully. It works for the first several clients, where a person can repeat the steps carefully each time. It becomes a bottleneck, and a source of inconsistency, as the number of instances grows. Every manual step is a chance for one instance to end up configured slightly differently from the others. Nobody notices until it causes a problem specific to that one client.

SalesCrew's platform roadmap includes automated one-click provisioning, where the steps above run as a single triggered workflow instead of a checklist, and a fleet heartbeat that monitors every client instance's health from one place. Neither is shipped today. Provisioning a new client instance is currently a deliberate, supported process. A prospective agency client cannot trigger it on their own as an instant self-serve signup.

Stating this plainly matters. It is a real trade-off built into the architecture, not a gap that reflects badly on the choice to go single-tenant. A product that promised instant self-serve provisioning on a single-tenant architecture before building the automation would be making a claim the infrastructure could not back. The honest position is that the isolation and export guarantees come with a provisioning problem that is still being solved, and the work is visible on the roadmap rather than assumed finished.

What does exist today is the piece that makes the automation worth building. Snapshot export and apply are shipped. The configuration side of a new instance, the stages, the cadences, the dispositions and the agent policy, can be carried over from an instance that already works, rather than rebuilt by hand. That is the part of setup that takes longest and is most likely to be done inconsistently, and it is already solved. What remains manual is standing up the project itself and connecting its credentials. That is the mechanical half, not the judgment half.

If you are evaluating a single-tenant product, ask one question directly. Not whether provisioning is automated, but what a new instance starts with once it exists. An instance that begins empty means every client is a fresh configuration project. An instance that begins from a snapshot of a working setup means the repeatable part is repeatable, and the automation still to come shortens the setup rather than changing what it produces.