Doesn't every SaaS product have settings? What makes this different?

Depth and reuse. Ordinary settings toggle a handful of preferences. The config described here sets the pipeline stages, cadence steps, agent policy and dispositions a whole team works inside. You can export it and apply it to a new instance as one object, instead of clicking it in again by hand.

Does config-driven mean every client gets the exact same feature set?

No, the opposite. Every client instance shares the same app code. Each instance sets its own active modules, pipeline shape, agent permissions and branding. So two clients on the same codebase can look and behave very differently.

What is a snapshot, in this context?

A snapshot is one client instance's config exported as a single object: its pipeline stages, cadences, dispositions and agent policy. You can apply it to a different client instance. A setup that worked for one client becomes a starting point you reuse, instead of one you rebuild by hand.

The config is the product

The code is the same for every client. What your customer actually feels is each instance's setup: its stages, cadences and agent policy.

app.salescrew.io/today

The short answer

Every client instance runs the same app code. What differs is config: which channels are on, the pipeline stages, cadence steps, dispositions and agent policy.
Treat config as a real object you can export, not settings clicked in by hand. That's what makes a client's setup reusable instead of a one-time effort.
A snapshot is a client instance's full config exported as one object, and you can apply it straight to a new instance. That only works once config is a real data model, not stray UI state.
Agencies resell SalesCrew as branded client instances. For them, the config layer is closer to what they sell than any single feature is.

Why the same code can feel like a different product

Two instances of the same CRM can look very different to the people using them. They can have different pipeline stages, different channels turned on, different agents in different modes, and a different brand. None of that needs a fork of the code. It needs the code to read its behavior from config instead of assuming it. Then the same app gives each client a different experience, based on what's stored in that client's own settings.

The other path is hardcoding what was true for one deployment. That's fine until a second client shows up with different channels, a different pipeline shape or a different brand. At that point, every hardcoded guess is a bug for the second client. A patch won't fix it. You have to pull each guess out into config after the fact, which is real engineering work. It has to happen at some point if the product will serve more than one deployment.

What actually has to be config, not code

Deployment settings decide which channels an instance uses (email, LinkedIn, inbound forms, Upwork) and which integrations are wired up. Pipeline config sets the stages a deal moves through, and what win chance or forecast group each stage implies. That varies a lot between a sale that closes in one call and one that runs for months.

Cadence config sets the steps a contact moves through in outreach. Disposition config sets the outcomes a rep can log against a call. Both depend on how your team sells. Agent policy sets which action classes are auto, review or human-only for that instance. A team at ease with automation may run a looser policy than one that wants every action 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 real, editable config is the true cost of one codebase serving many kinds of client. Baking those values into the code would be cheaper, and it wouldn't scale.

Why this matters more once configuration is reusable

Once config is a real object, not stray UI state, you can treat it as a thing of its own. You can export it, version it and apply it elsewhere. SalesCrew snapshots are exactly that. A snapshot is one client instance's pipeline, cadences, dispositions and agent policy, exported as one object and applied straight to a new client instance. That works because the config underneath is structured data with a set shape. It isn't a trail of clicks in an admin panel that left nothing you can reuse.

Say you're an agency reselling a configured CRM to several clients. For you, this is the part of the product that does the reselling work. One well-designed feature helps every client a little. A proven setup does more. Take the pipeline shape and cadences that worked for one client in a trade, and apply them to the next client in that trade. "We set up one client well" becomes a business you can repeat. Shared app code is the groundwork. Your client notices the config layer on top.

Questions

Doesn't every SaaS product have settings? What makes this different?: Depth and reuse. Ordinary settings toggle a handful of preferences. The config described here sets the pipeline stages, cadence steps, agent policy and dispositions a whole team works inside. You can export it and apply it to a new instance as one object, instead of clicking it in again by hand.
Does config-driven mean every client gets the exact same feature set?: No, the opposite. Every client instance shares the same app code. Each instance sets its own active modules, pipeline shape, agent permissions and branding. So two clients on the same codebase can look and behave very differently.
What is a snapshot, in this context?: A snapshot is one client instance's config exported as a single object: its pipeline stages, cadences, dispositions and agent policy. You can apply it to a different client instance. A setup that worked for one client becomes a starting point you reuse, instead of one you rebuild by hand.