One CRM per client. One database each.

Most agencies resell a CRM the same way: one platform account, every client a sub-account inside it, all of them sharing one database. That works until a client asks where their data lives, or leaves and wants it back, or a permission mistake shows one client something belonging to another. The shared tenant is the thing that breaks.

SalesCrew is built the other way round. Each client instance is its own Supabase project: a separate Postgres database, its own file storage, its own edge functions, and a region you pick when the instance is created. There is no shared row, no tenant column, and no query that could cross from one client to another because there is no shared table to cross. Export means a full Postgres dump, not a set of CSVs with the relationships stripped out.

The second half is the part that decides whether you can let an agent near a client account at all. Every agent in SalesCrew runs in a mode you choose: off, draft, review or auto. Every external send, whether an email, a LinkedIn message or a marketplace proposal, sits in an approval queue by default until someone reads it. Every tool call, whether a person, a token or an agent made it, is written to the audit log. When a client asks what the AI did on their account last Tuesday, you can answer with a record instead of a guess.

Your cost per client is the tier price plus metered usage. The Agency tier is $1,200 a month per instance with unlimited seats and an allowance of about 60,000 model calls a month. Metered means model calls today, and SMS segments and call minutes once the voice pack ships. There is no wholesale rate to build a plan on, because partner billing is on the roadmap.

That means the margin is in the service layer, not in a software markup, and it is worth being clear-eyed about it. Your client can find our pricing page. What they cannot do themselves is the configuration, the campaign work, the reporting, and being accountable when a sequence goes wrong on a Friday. That is what you are pricing.

Decide the pass-through rule before the first invoice rather than after a heavy month. Bundle an allowance and bill overage, bill the platform at cost and charge for the service separately, or set one flat price high enough to absorb a spike. The AI cap is a hard stop at 100 percent for AI work only, so a client who burns their allowance loses the model features and keeps every manual path.

Every other feature on this page is negotiable. This one is the reason the product exists.

A multi-tenant CRM stores every customer in one database and separates them with a column and some application logic. That design is fine when the vendor is the only party who cares. It stops being fine when you are the middle layer: you carry the risk of a mistake you cannot see, you cannot show a client their own isolation, and you cannot hand over anything more than an export file if they leave.

Single-tenant changes three conversations at once. The security conversation gets short, because the answer is a project boundary rather than a policy. The data residency conversation gets a real answer, because the region is chosen per client when their project is created. The exit conversation stops being a negotiation, because the whole database is theirs to take and the export is a Postgres dump with every relationship intact, not a folder of CSVs.

There is a cost to this, and it is honest to name it. One project per client means one set of infrastructure per client, which is why the price is per instance rather than per seat. It also means a change you want on every client account is a change you apply to each of them. Snapshots exist to solve exactly that, and they are on the roadmap rather than in the product today.

A client can also bring their own AI key. The key goes into the instance's secrets vault, is never displayed again, and their model spend stops flowing through your allowance. For agencies with a client who has an existing model contract, that removes an argument before it starts.