What "build" actually means
Most build cases are argued from the first release: earn, burn, a balance, an app. They are rarely argued from year three, when the program has hundreds of promotions, several brands, partner-funded offers, an auditor asking for lineage, a second data warehouse and a migration to the next thing. The table below lists what the build has to deliver by then.
| Capability | Why it arrives |
|---|---|
| Deterministic real-time engine at the transaction | The register and the pump cannot wait for a batch job |
| Discount arbitration across overlapping offers | Dozens of offers on one basket, some vendor-funded, some exclusive |
| Point-level lineage and a liability rollforward | Finance and audit will ask; breakage must be observed, not assumed |
| Partner wallets and settlement with date-relative billing | Partners fund rewards and settle weeks later at changed rates |
| Environments, versioning, approval, audit, rollback | Multiple teams change the same program; mistakes are expensive |
| APIs, events and batch feeds | Every enterprise system becomes a consumer of loyalty data |
| Member care tools with bounded authority | Agents must adjust, reverse and merge without engineering |
| Security assurance | Procurement will ask for attestations and certifications |
| A migration path | Every platform is eventually replaced; the build must be leavable |
Where the cost sits
Most of what a program costs comes after launch, in the changes nobody planned for. In a build, every change is an engineering ticket and every new mechanic is a project. In a bought platform with a closed configuration layer, every change beyond the vocabulary is a vendor change request. Both fail the same test in different ways: the marketing calendar outruns the release calendar.
The middle path: a programmable platform
The build-versus-buy framing assumes that buying means accepting the vendor's feature list as a ceiling. A programmable platform changes the question. ReactorCX ships a self-service configuration layer on a fully programmable core: when a requirement exceeds the configuration UI, custom code and net-new functionality can be built inside the platform, versioned and audited like the rest of the program, without waiting on a roadmap. Enterprises have added household-level tiers and custom recognition mechanics this way. The published feature set is a floor, not a ceiling, and the ledger, engine, governance and migration method come with it.
Questions to settle before deciding
- Who will own the ledger in year three, and can they reproduce the liability rollforward from it?
- What is the time from a marketer's idea to production, and who is on the critical path?
- What happens to the program when the engineers who built it move on?
- How will the program migrate off whatever you choose now, and how will you prove the migration?
- What independent assurance will procurement and customers require, and who will maintain it?