Agency embedding Sanity Studio per client app, how do we keep Croct tidy?
We are a Dutch agency shipping Next.js apps with an embedded Sanity Studio per client. Three of those clients are now getting personalization, and I want to set up the Croct side properly before the first one goes live.
My concerns, in order:
- Separation. Client A's audiences, slots, and analytics must be invisible to client B, and to whichever developer is only assigned to B.
- Environments. Each app has a staging and a production deployment, and I want experiments testable on staging without polluting production data.
- Does embedding the Studio inside the Next.js app (rather than hosting it separately) change anything about the integration?
How are other agencies structuring this?
1 answer
We run a very similar setup for five clients, here is what held up.
For separation, one Croct workspace per client. Workspaces are the isolation boundary, so slots, audiences, experiences, and analytics never mix, and you grant people access per workspace, which answers your developer-assignment concern too.
For environments, each application in a workspace supports several, so pair your staging deployment with the dev environment and production with prod. Experiments you poke at on staging never touch production numbers.
To make this repeatable, lean on the croct.json5 file in each repo. It pins the organization, the workspace, and the applications per environment, so a checkout plus the right env vars is all a new developer needs. When we onboard a client we copy the file from our template repo and change three values.
On question 3: it does not matter where the Studio lives. The integration is entirely frontend-side, you map Sanity components to Croct slots in the app code, and the Studio (embedded or hosted) keeps editing the default content exactly as before. Nothing in the Studio setup needs to change.