Snapshot or custom build — how to decide

A snapshot is a saved configuration — pipelines, workflows, calendars, forms, custom fields — that can be loaded into a new sub-account. It turns a two-week build into an afternoon.

That is the pitch and it is true. The part that gets left out is what happens on client twenty-three.

When a snapshot is clearly right

Your clients genuinely do the same thing. Fifteen roofing companies have close to the same lead flow: enquiry, survey, quote, follow-up, job. One snapshot fits all fifteen well.

You are selling a productised offer. If the deliverable is defined and the same every time, the snapshot is the product.

Speed is the differentiator. Onboarding a client in a day rather than a fortnight changes what you can charge and how many you can carry.

You want consistency you can support. Fifteen bespoke builds is fifteen things to debug. One snapshot deployed fifteen times is one.

When a snapshot is clearly wrong

The sales process actually differs. Not “differs in labels” — differs in stages, in who does what, in what triggers a handover. Forcing those into a shared shape produces a system nobody uses and a client who blames the platform.

Integrations are client-specific. A snapshot cannot carry the credentials, endpoints or field mappings of a client’s own systems. The more of the value sits in those integrations, the less a snapshot carries.

The data model is different. Custom fields and objects are the hardest thing to change after records exist. Getting them wrong to save setup time is the most expensive possible trade.

It is a lighthouse client. The first client in a new vertical is research. Build it properly, learn what the vertical actually needs, then snapshot it.

What snapshots do not carry

This is the part that surprises people mid-migration:

• Credentials and API keys. Every integration is reconnected per sub-account.
• Phone numbers. Provisioned and configured per account.
• Domains and DNS. Per client, always.
• Historic data. A snapshot is structure, not records.
• Some settings silently. Behaviour that depends on account-level configuration can differ after import in ways that only surface in testing.

Which is why “deploy the snapshot” is the start of an onboarding checklist, not the whole of it.

The hybrid most agencies land on

A core snapshot carrying the things that genuinely are universal: pipeline skeleton, naming conventions, tagging taxonomy, the standard follow-up sequences, a working calendar setup, and the compliance plumbing.

Then a short custom layer per client: their integrations, their specific stages, their messaging, their booking rules.

Roughly 80% loaded, 20% built. Fast enough to be profitable, flexible enough to be correct.

Maintaining a snapshot is real work

The failure mode nobody plans for: you improve the snapshot on client thirty, and clients one through twenty-nine are still running the old version. Updates do not propagate backwards.

Before you scale a snapshot, decide:

• How you version it, and how you know which client has which version
• Whether you retrofit improvements, and who pays for that time
• What you do when a platform change breaks a workflow across every account at once

That last one is the argument for consistency over bespoke, and it is the strongest one. When something breaks across thirty identical builds, you fix it once and know where it applies.