The config is the product
The code is the same for every client. What each instance is configured to do, its stages, cadences and agent policy, is what a customer actually experiences.
The short answer
- Every client instance runs the same application code. What differs is configuration: which channels are active, the pipeline stages, cadence steps, dispositions and agent policy.
- Treating configuration as a first-class, exportable object, rather than settings clicked by hand, is what makes a client's setup reusable instead of a one-time effort.
- A snapshot, a client instance's full configuration exported as one object, can be applied to a new instance directly. That only works once configuration is a real data model, not scattered UI state.
- For a product resold by agencies as branded client instances, the configuration layer is closer to the product an agency sells than any single feature is.
Why the same code can feel like a different product
Two client instances of the same CRM can look very different to the people using them. Different pipeline stages, different channels turned on, different agents running in different modes, a different visual brand. None of that needs a fork of the codebase. It needs the codebase to read its behavior from configuration rather than assume it. The same deployed application then produces a different experience per client, based on what is stored in that client's own settings.
The alternative is hardcoding assumptions that were true for one deployment. That is fine until a second client exists with a different set of channels, a different pipeline shape, or a different brand. At that point every hardcoded assumption is a bug for the second client. The fix is not a patch. It is pulling that assumption out into configuration after the fact, which is real engineering work. It has to happen at some point if the product is meant to serve more than one deployment.
What actually has to be config, not code
Deployment-level settings decide which channels an instance uses, email, LinkedIn, inbound forms, Upwork, and which integrations are wired up. Pipeline configuration decides the stages a deal moves through and what probability or forecast category each stage implies. That varies a lot between a sales motion that closes in one call and one that runs for months. Cadence and disposition configuration decides the steps a contact moves through in outreach, and the outcomes a rep can log against a call. Both are specific to how a team sells. Agent policy configuration decides which action classes are auto, review or human-only for that instance. A team comfortable with automation may run a looser policy than one that wants everything reviewed.
None of these are settings in the small sense. Each is closer to a data model of its own. Pipeline stages have their own table. Cadence steps have their own structure, with branching. Agent policy is a full table of action classes and default modes. Building all of that as first-class, editable configuration, rather than values baked into application logic, is the real engineering cost of making one codebase serve many differently shaped clients.
Why this matters more once configuration is reusable
Once configuration is a real object, not scattered UI state, it can be treated as an artefact: exported, versioned, and applied elsewhere. A snapshot in SalesCrew is exactly that. One client instance's pipeline, cadences, dispositions and agent policy, exported as one object and applied to a new client instance directly. That works because the configuration underneath is structured data with a defined shape. It is not a set of clicks someone made in an admin panel that left no reusable trace.
For an agency reselling a configured CRM to multiple clients, this is the part of the product that does the reselling work. A single well-designed feature helps every client a little. A proven configuration, the pipeline shape and cadence structure that worked for one client in a trade, applied to the next client in the same trade in minutes, turns "we configured one client well" into a repeatable business. Shared application code is the prerequisite. The configuration layer on top is what an agency's client actually notices.
Questions
- Doesn't every SaaS product have settings? What makes this different?
- Depth and reusability. Ordinary settings toggle a handful of preferences. The configuration described here defines the pipeline stages, cadence steps, agent policy and dispositions a whole team works inside. It can be exported and applied to a new instance as one object, not re-clicked by hand.
- Does config-driven mean every client gets the exact same feature set?
- No, the opposite. The application code is shared across every client instance. Which modules are active, how the pipeline is shaped, what the agents may do, and how the product is branded are all set per instance. Two clients on the same codebase can look and behave differently.
- What is a snapshot, in this context?
- A snapshot is one client instance's configuration, its pipeline stages, cadences, dispositions and agent policy, exported as a single object that can be applied to a different client instance. A configuration proven on one client becomes a reusable starting point instead of being rebuilt by hand.