Implementation worksheet · 6 min read
A Build-Versus-Buy Worksheet for Customer Engagement
List the capabilities your lifecycle program needs over the next 12 to 24 months, mark each as differentiating or commodity, and cost the build honestly, including the parts a prototype never shows: journey state held across days, frequency caps across channels, consent and suppression enforcement, a preference center, retries when a channel provider fails, audit logs, and the tooling marketers need to change a journey without an engineer. Buy the commodity layer unless a verified hard constraint forces you to build it. Build where the logic is your differentiation, and feed its output into whatever you buy. Decide per capability rather than once for the whole stack; either way, compliance stays your responsibility.
Scope: a head of growth and an engineering lead deciding whether to build lifecycle messaging in-house (warehouse, scheduler, channel provider APIs) or buy a customer engagement platform. Starting state: transactional email through a provider API and a few scheduled scripts. Boundary: lifecycle messaging across email, push, in-app and SMS for the next two years. Intended outcome: a decision per capability, with the build estimate, the buy coverage and the reason written next to each.
Put it into practice
1. List capabilities from planned journeys, not a feature list
Start from the journeys you intend to run in the next two years (onboarding, trial conversion, win-back, renewal) and list what each needs. A vendor's feature list pads the build side with things you won't use; your own journeys keep the comparison honest.
2. Mark each capability differentiating or commodity
Differentiating means a competitor couldn't match it by buying the same tool: a recommendation model trained on your product usage, account logic specific to your pricing. Journey scheduling, frequency caps and preference centers rarely set a business apart; mark them differentiating only if you can say why.
3. Cost the build in engineer-weeks, initial plus yearly
Use your own team's estimates, and include what a prototype skips: state for people partway through a journey, retries and provider failover, idempotent sends so that a retry doesn't message someone twice, suppression across journeys, audit logs, and an interface marketers can use. Maintenance is a yearly cost, not a one-off.
4. Cost the buy at your projected volume
A written quote at the contact and message volumes you expect in 24 months, integration work, keeping data in sync, the capability gaps you would still have to build, and the cost of leaving: how events, profiles and consent records come out at the end.
5. Apply the compliance floor to both options
Either way you process opt-outs: the FTC's CAN-SPAM guidance requires email opt-outs to be honored within 10 business days, and says hiring another company doesn't transfer the legal responsibility. Google's sender guidelines (as of September 2026) require one-click unsubscribe on marketing messages from senders of more than 5,000 messages a day to Gmail accounts; the signaling method is standardized in RFC 8058. If you build, you build these. If you buy, you verify them.
6. Check hard constraints in writing
A data-residency requirement no vendor meets, a channel no vendor supports, a unit cost at your volume that no vendor can approach. Confirm each in writing with the vendors before it decides anything; an assumed constraint is an expensive reason to build.
7. Worked example (illustrative, synthetic numbers)
A B2B SaaS company with two lifecycle marketers scores nine capabilities. Building all of them is estimated at 54 engineer-weeks up front and 19 a year to maintain. Seven are commodity and covered by the platforms it evaluated, so it buys those. It builds the next-best-action model, which runs on its own product data, and sends the model's output to the platform as a profile attribute. Seat-aware account journeys are split: the platform's account-level journeys, plus a small in-house service for the seat logic.
Build-versus-buy worksheet (illustrative estimates)
Copy this structure into your review document and record your observed result for each row.
| Capability | Differentiating? | Build: initial + yearly (engineer-weeks) | Covered by buying? | Decision |
|---|---|---|---|---|
| Event-triggered journeys with multi-day state | No | 12 + 4 | Yes | Buy |
| Cross-channel frequency caps | No | 4 + 1 | Yes | Buy |
| Consent, suppression and opt-out processing | No, but compliance-critical | 5 + 2 | Yes; the responsibility stays with you | Buy, then audit |
| Preference center | No | 3 + 1 | Yes | Buy |
| Provider retries and failover | No | 4 + 2 | Partly | Buy; test failover before signing |
| Journey editing without engineers | No | 10 + 3 | Yes | Buy |
| Audit log of sends and changes | No | 2 + 1 | Yes | Buy; confirm the export |
| Next-best-action model on product data | Yes | 8 + 3 | No | Build; send its output as a profile attribute |
| Seat-aware account journeys | Partly | 6 + 2 | Partly | Buy the base; build the seat logic |
| All nine, if built | Not applicable | 54 + 19 | Not applicable | Compare with the written quote |
A failure worth checking
The prototype comparison. Engineering ships a working three-email drip in two weeks and concludes that building is cheaper than any quote. The prototype has no frequency caps, no suppression across journeys, no preference center, no retry logic and no way for a marketer to change the day-3 copy. Six months later every copy change is an engineering ticket. Verification: cost both options against the full capability list, and ask one concrete question of each: who changes the day-3 message of the onboarding journey, and how long does it take?
Common questions
When does building the whole stack make sense?
When a verified hard constraint rules vendors out, or when messaging is itself your product. Get the constraint confirmed in writing by the vendors you would otherwise buy from; a constraint nobody checked is not a reason.
Doesn't buying mean lock-in?
Some. Reduce it by keeping the source of truth for events and consent in your own systems, and by confirming before you sign how profiles, events and consent records can be exported when the contract ends.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.