Standing up a new client instance
A new client gets their own Postgres project, not a partition inside someone else's. Here is what gets created, what gets configured, and what a person still decides.
- One database per client
- Region chosen per client
- Every setup step has an MCP tool
The short answer
- Create the project: a new Supabase project for that client alone, meaning its own Postgres database, storage and edge functions, in a region chosen for them at creation.
- Configure it: pipeline stages, ICPs, segments, cadences, suppression, mailboxes, calendar and agent policy, each of which has an MCP tool as well as a screen, so the setup can be scripted.
- Hand it over in review mode: agents start in review, every external send waits in an approval queue, and every tool call is written to an audit log naming whether a person, a token or an agent did it.
Trigger to logged
What happens at each stage, and what is visible while it happens.
- 1
Trigger: a client is signed
An agency decides a new client needs an instance and picks the region their data must live in. This is a human decision because it sets data residency and cannot be changed by moving a row later.
- 2
SalesCrew creates the project
A dedicated Supabase project is created for that client: Postgres database, file storage and edge functions, plus the MCP endpoint served from that instance. Automated provisioning is on the roadmap, so today this step is run by a person rather than triggered by a signup.
- 3
The human sees an empty, isolated instance
The instance answers on its own subdomain with no records in it. There is no other client's data to filter out, because nothing else was ever written to this database.
- 4
Configuration is applied
Stages, dispositions, ICPs, segments, cadences, suppression entries, mailbox and calendar connections and agent policy. Each has both a screen and an MCP tool with an identical effect, so an agency can run a standard setup script instead of clicking through every screen.
- 5
Credentials go into the vault
Mailbox passwords, API keys and any client-supplied AI key are stored in the instance's Supabase Vault and are never displayed again after entry. A client bringing their own AI key keeps their model spend off your allowance.
- 6
Agents start in review, and everything is logged
Every agent ships in review mode. Drafts queue for a human, and rejections feed the next run. Every tool call, by a person, a token or an agent, is written to the audit log with the actor named, so the record of what happened on this account starts on day one.
What gets configured on a new instance
Each row is set once at provisioning and can be changed later from either the app or an MCP tool.
| What | Set at provisioning | Why it is decided here |
|---|---|---|
| Project and region | A dedicated Supabase project: Postgres, storage and edge functions, in a chosen region | Residency is a property of where the project lives, so it is set at creation rather than adjusted later |
| Pipeline | Stages, probability per stage, dispositions | The forecast is only meaningful once stages match how the client's sales actually works |
| Audience | ICPs, segments, suppression list imported before any sending | Suppression must exist before the first campaign, not after it. It is re-checked when an audience is frozen and again at send time |
| Channels | Mailboxes over IMAP and SMTP, calendar, inbound forms and webhooks | Each connection is authenticated per instance and its credentials live in that instance's vault |
| Agents | Modes per agent, the guardrail set, and the kill switch owner | Agents ship in review by default. Deciding who can move one to auto is an access decision, not a setting to leave at its default |
| Access | Users, roles and the three-axis scope model of channel, profile and area, plus MCP tokens scoped the same way | The same scopes apply to the interface and to MCP tokens, so an agent cannot reach past what its owner can |
Where it stops and a human starts
Creating the project is a human step today. Automated provisioning is on the roadmap, which means an agency signing a client this week runs the setup rather than triggering it from a form. That is worth planning around if you expect to open several clients in a week.
Choosing the region is a human decision on purpose. It sets where the client's records live and it is not a preference to be flipped afterwards, so it belongs in the conversation with the client rather than in a default.
Moving an agent from review to auto is a human decision every time. The default policy keeps research, enrichment, tagging, scoring, reply classification and pausing a cadence on reply in auto, and holds every external send in review. Changing that is deliberate, and anything involving spend stays human-only regardless of mode.
Two things a person still does by hand: applying a standard setup to an already-running client, because snapshot export and apply are on the roadmap, and putting your own brand on the app, because branding is on the roadmap too. Both are real gaps today and neither is worth describing as though it ships.
Questions
- How is this different from creating a sub-account?
- A sub-account is a partition inside a platform's existing database. An instance is its own Supabase project, meaning its own Postgres database, its own file storage and its own edge functions, created in a region you choose for that client. The practical difference shows up in three places: a mistake in one client's project cannot reach another, an export is the whole database rather than files pulled out of a shared one, and residency is set per client instead of per platform.
- Can I script the setup instead of clicking through it?
- Yes, and that is the intended path for an agency running more than a couple of clients. Every action in the app is also an MCP tool with the same effect, so stages, cadences, segments, ICPs, suppression entries and agent policy can all be created by a script or by an agent connected over MCP. It is not a one-click snapshot, which is on the roadmap, but it does mean the standard setup lives in a file you maintain rather than in someone's memory.
- What does the client see during provisioning?
- Their instance on its own subdomain, and whatever you have configured before you hand over the login. Branding, meaning your name, logo, theme and a client subdomain of your own, is on the roadmap, so today the app does not carry your brand. That is worth saying to a client at the start rather than letting them discover it at the demo.