THE SHORT VERSION
- Under three clients of the same type, a library snapshot always wins on maths.
- Custom builds pay for themselves through redeployment, not through the first account.
- A cloned sub-account is not a snapshot — it carries dead references and collides on reinstall.
- The hybrid route — licence a library snapshot, build your process on top — is usually the cheapest good answer.
This decision gets made emotionally more often than it gets made with a spreadsheet. Agencies who like building want a custom snapshot. Agencies who are tired want a library one. Both can be wrong.
Here is the framework that actually decides it.
The maths, first
A custom snapshot build is worth it when the redeployment saving exceeds the build cost, and nothing else matters.
Say a client account of a given type takes you 34 hours to build by hand, and a properly built snapshot brings that to 6. That is 28 hours saved per deployment. At a $95 internal cost per hour, each redeployment is worth about $2,660.
A custom snapshot build starting at $4,500 breaks even at two deployments and is clearly profitable at three. That is the whole calculation, and it is why the honest answer for an agency with one client of that type is always “do not”.
But note what it assumes: that the snapshot is genuinely redeployable. Which brings us to the trap.
The clone trap
Almost every agency’s first attempt at “our own snapshot” is a cloned sub-account. It works once, on the account it was cloned from, and then falls apart on the second install because:
- Assignments point at people who do not exist in the destination account.
- Calendar references point at calendars owned by someone else.
- Absolute media URLs point back at the source account’s file library.
- Tags and pipelines collide with anything else installed there.
- Client-specific strings are hard-coded into forty templates instead of living in custom values.
A redeployable snapshot is a different thing from a copy. It needs a prefixed naming scheme, every client-specific string in a custom value, no absolute references, and a documented install order. That architecture is most of what you are paying for in a custom build, and it is the part agencies consistently underestimate when they decide to do it themselves.
When a library snapshot is right
Buy from the library when:
- You have one or two clients in that vertical, or you are testing whether the vertical works for you at all.
- You want to prove the model this month rather than next quarter.
- Your process for that client type is not yet stable — building a custom snapshot around a process you are still changing means building it twice.
- The vertical is well covered. Home services, med spa, dental, real estate and legal are solved problems; you are not going to out-think a snapshot that has been through two thousand installs.
The cost of being wrong here is a few hundred dollars. The cost of being wrong about a custom build is several thousand plus a month.
When a custom build is right
Commission one when:
- You have three or more clients of the same type and can see more coming.
- Your delivery process is genuinely differentiated — it is the thing clients pay you for, and a generic vertical snapshot fights it.
- You are running SaaS mode and every new sub-account should provision from your own standard.
- You need specific integrations or reporting that no library snapshot will ever include.
- The knowledge currently lives in one person’s head and you would like it to live in a system instead.
That last one is underrated. A custom snapshot is documentation that executes.
The hybrid, which is usually the right answer
The route most agencies should take and few consider: licence a library snapshot into your agency, then have your process built on top of it.
You are not paying to have speed-to-lead logic invented again. That exists, it is tested, and it works. You are paying for the twenty percent that is yours — your qualification standard, your reporting, your onboarding, your naming.
In practice that takes about a week off a custom build timeline and a meaningful amount off the quote, because the foundation is not being rebuilt from nothing. It is also lower risk: you are customising something that has already been built, tested and documented rather than shipping v1 of a design.
A quick decision table
| Situation | Buy |
|---|---|
| One client, common vertical | Library snapshot |
| Two clients, testing the vertical | Library snapshot |
| Three-plus clients, stable process | Custom build |
| Three-plus clients, process still changing | Library snapshot now, custom build in a quarter |
| SaaS mode with a standard offer | Custom build |
| Differentiated delivery you sell on | Custom build |
| Common vertical, distinctive reporting | Hybrid |
The failure mode to avoid
The expensive mistake is neither of these. It is building a custom snapshot informally — cloning, patching, cloning again — so that you pay the custom-build cost in scattered hours without ever getting the redeployable asset at the end.
If you have rebuilt the same client type four times, you have already spent the money. The only question left is whether you get an asset for it.