Why does an agency care about database architecture instead of just features?

Because an agency's standing with its clients rests on its data promises being true. Promises about ownership and isolation can't be only sales talk. A shared database undercuts them by its structure, however the agency words its pitch.

Is a snapshot the same thing as a template?

They aim at the same goal but hold different things. A snapshot exports a client instance's actual setup as one object: pipeline stages, cadences, dispositions and agent policy. A template is a document that tells you what to click through by hand.

What does a database per client let an agency promise?

It lets an agency make isolation and export promises that a shared database can't back. Each client's data lives only in its own project. On churn, the client gets read-only access and a full export, and deprovisioning after 90 days is a step a person triggers.

The agency model that runs on one database per client

An agency reselling a CRM must tell clients their data is theirs. That promise only holds up if the design backs it.

app.salescrew.io/today

The short answer

When you resell a CRM, you make promises about data ownership and isolation on the vendor's behalf. Those promises are only as true as the design underneath.
A shared, multi-tenant database undercuts your isolation promise. Your client's data sits in the same tables as every other client of every agency on the platform.
SalesCrew gives each client its own Supabase project. So you can tell a client their data lives in its own database and mean it literally, with a real export behind it.
A snapshot is a client's setup exported as one object and applied to a new client. It turns a proven setup into an asset you reuse, which matters more to an agency than to one end customer.

The claim an agency has to make, and what backs it up

When you resell a CRM to your own clients, you make promises on top of a product you didn't build. The client's data is theirs. Other clients won't see it. It can be handed over cleanly if the work ends. Those are fair things for a client to expect. Your standing depends on backing them with more than a line in a sales deck.

Now say the platform is multi-tenant, with one shared database for every client of every agency. Those promises get harder to make honestly. Isolation rests on access rules staying correct. A full export rests on the vendor building a CSV export for whichever objects it chose to expose. You can still say "your data is isolated." But the design does less to make that literally true than the words suggest.

Why single-tenant changes what an agency can honestly say

SalesCrew gives each client instance its own Supabase project, with its own Postgres database, storage and edge functions. That changes what you can say and mean when you resell it. "Your data lives in its own database" is a literal fact a client can check. It isn't a shorthand for an access policy on shared tables.

Say a client asks what happens to their data when they leave. The honest answer is read-only access, then a full export, then deprovisioning after 90 days, as a step a person chooses to take. That works because the client's project never held anyone else's data to get in the way of the handover.

Data residency works the same way. Setting up a client means creating a new database project, so you can pick the region for that client. That matters if your clients work in different countries, with different rules about where data lives. A shared-database platform can't offer that choice per client. A single-tenant one can, because each client's setup is separate from the start.

Where the reselling advantage comes from: the snapshot

Isolation and export build trust. The part of this design that helps your margins is the snapshot. A client instance's setup is exported as one object and applied straight to a new client instance. That setup covers its pipeline stages, cadence steps, dispositions and agent policy. Because each instance is its own project with its own settings, a snapshot is a real, structured copy of how this client is set up. It isn't a document listing settings to re-click by hand.

Say you sign a new client in a trade you already serve. You apply a proven snapshot from an existing client, then adjust what's specific to the new one. Hand setup gives way to a proven starting point. That gain grows each time you sign a client like one you've already set up well. It's how the design becomes a business edge, not only a trust story you tell each client one at a time.

Questions

Why does an agency care about database architecture instead of just features?: Because an agency's standing with its clients rests on its data promises being true. Promises about ownership and isolation can't be only sales talk. A shared database undercuts them by its structure, however the agency words its pitch.
Is a snapshot the same thing as a template?: They aim at the same goal but hold different things. A snapshot exports a client instance's actual setup as one object: pipeline stages, cadences, dispositions and agent policy. A template is a document that tells you what to click through by hand.
What does a database per client let an agency promise?: It lets an agency make isolation and export promises that a shared database can't back. Each client's data lives only in its own project. On churn, the client gets read-only access and a full export, and deprovisioning after 90 days is a step a person triggers.