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

Because an agency's credibility with its clients depends on its claims about data ownership and isolation being true, not only marketing language. A shared database undercuts those claims structurally, however the agency phrases its pitch.

Is a snapshot the same thing as a template?

Similar in intent, different in what it captures. A snapshot exports a client instance's actual configuration, pipeline stages, cadences, dispositions and agent policy, as one object. A template is a document describing what to click through by hand.

Does single-tenant architecture cost an agency more per client?

The infrastructure cost is generally higher for a dedicated database per client than for a shared one, and that real cost is passed through in pricing. What it buys the agency is the ability to make isolation and export claims to its own clients that a shared database could not support.

The agency model that runs on one database per client

An agency reselling a CRM has to tell its own clients their data is theirs. That claim only survives a real question if the architecture backs it up.

app.salescrew.io/today

The short answer

An agency reselling a CRM makes claims about data ownership and isolation on the vendor's behalf. Those claims are only as true as the architecture underneath.
A shared multi-tenant database undercuts an agency's isolation claim. A client's data sits in the same tables as every other client of every agency on the platform.
SalesCrew's single-tenant architecture, one Supabase project per client, lets an agency tell a client their data lives in its own database and mean it literally, with a real export behind it.
Snapshots, a client's configuration exported as one object and applied to a new client, turn a proven setup into a repeatable asset. That matters more to an agency's business than to one end customer.

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

An agency reselling a CRM to its own clients is making promises on top of a product it did not build. The client's data is theirs. It will not be exposed to other clients. It can be handed over cleanly if the relationship ends. Those are reasonable things for a client to expect. The agency's credibility depends on backing them with more than a sentence in a sales deck.

If the platform is multi-tenant, one shared database serving every client of every agency, those promises are harder to make honestly. Isolation depends on access-control rules staying correct. A full export depends on the vendor choosing to build a CSV extraction for whichever object types it decided to expose. The agency can still say "your data is isolated". The architecture is doing less to make that literally true than the words imply.

Why single-tenant changes what an agency can honestly say

SalesCrew's architecture gives each client instance its own Supabase project: its own Postgres database, storage and edge functions. That changes what an agency reselling it can say and mean. "Your data lives in its own database" is a literal, checkable fact, not a simplification of a shared-table access policy. If 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 deliberate step. That is possible because the client's project never held anyone else's data to complicate the handover.

Data residency works the same way. Provisioning a client means creating a new database project, so the region can be chosen for that client. That matters for an agency whose clients operate in different jurisdictions, with different expectations about where data physically lives. A shared-database platform cannot offer that choice per client. A single-tenant one can, because each client's infrastructure is separate from the start.

Where the reselling advantage comes from: the snapshot

Isolation and export are the trust foundation. The part of this architecture that helps an agency's economics is the snapshot. A client instance's configuration, its pipeline stages, cadence steps, dispositions and agent policy, is exported as one object and applied to a new client instance directly. Because each instance is its own project with its own configuration, a snapshot is a real, structured export of "how this client is set up". It is not a document describing settings to re-click by hand.

When an agency onboards a new client in a trade it already serves, applying a proven snapshot from an existing client turns days of manual configuration into a starting point applied in minutes, then adjusted for what is specific to the new client. That compounds every time the agency signs a client that resembles one it has already configured well. That is how the architecture becomes a business advantage, not only a trust story told to each client one at a time.

Questions

Why does an agency care about database architecture instead of just features?: Because an agency's credibility with its clients depends on its claims about data ownership and isolation being true, not only marketing language. A shared database undercuts those claims structurally, however the agency phrases its pitch.
Is a snapshot the same thing as a template?: Similar in intent, different in what it captures. A snapshot exports a client instance's actual configuration, pipeline stages, cadences, dispositions and agent policy, as one object. A template is a document describing what to click through by hand.
Does single-tenant architecture cost an agency more per client?: The infrastructure cost is generally higher for a dedicated database per client than for a shared one, and that real cost is passed through in pricing. What it buys the agency is the ability to make isolation and export claims to its own clients that a shared database could not support.