Build vs Buy and Platform Costs
The goal is a reliable capability, not a maximal platform. A plain file, database, CI job, or script can be the right design when scale and coordination are small. Products become valuable when they remove enough repeated work or risk to justify integration, migration, policy, and on-call ownership.
Prerequisites
Complete Security, Privacy, and Supply-Chain Risk and the preceding platform-tool lessons.
Learning goals
- translate lifecycle needs into service levels, controls, and owner responsibilities.
- estimate total cost of ownership rather than license or infrastructure alone.
- prefer reversible experiments and interoperable evidence formats.
Worked example
Score the Study Sprint options against explicit needs:
| Need | Smallest credible option | Platform trigger |
|---|---|---|
| Compare a few runs | committed run.json and CSV | many users need indexed search, UI, retention, and access policy |
| Rebuild a file graph | script or build target | large artifacts need content-addressed cache and remote sharing |
| Reuse three features | shared preprocessing and database view | many teams need point-in-time sets and low-latency materialization |
| Run on merge | one least-privilege CI job | queues, environments, approvals, and reusable policies span repositories |
| Schedule one lifecycle | cron or CI schedule | dependencies, backfills, retries, concurrency, and operators grow |
| Register one model | versioned JSON manifest | discovery, permissions, aliases, attestations, and audit scale across teams |
For each option, estimate build/integration time, license and compute, storage/egress, upgrades, security review, identity/access, backups, observability, incident response, support, training, migration, lock-in, and opportunity cost. That is the total cost of ownership. Include failure cost and the cost of proving controls, not just average monthly spend.
Run a bounded pilot with exit criteria: time to reproduce a run, add a user, rotate access, restore backup, trace lineage, roll back, export metadata, and respond to a simulated incident. Prefer open artifacts and stable APIs so evidence can move even if the product changes. Assign a service owner before adoption.
For Study Sprint, the repository's plain JSON/Markdown/CLI design wins: one team, tiny committed data, deterministic local runs, and no online feature lookup. That conclusion would change with more teams, sensitive data, strict availability, or regulated approval workflows.
Common mistakes
- Buying a stack before naming users, decisions, service levels, and owners.
- Comparing license cost with in-house build time while omitting operations.
- Assuming managed means no security, integration, or incident responsibility.
- Custom-building commodity identity, audit, backup, or scheduler behavior.
- Locking data and lineage into a product without an export and exit test.
Practice
Create a weighted scorecard for run tracking, feature reuse, or orchestration. Use current and two-year scale, name the owner, price one outage, and define a stop/exit condition.
Next steps
Complete Project: Train, Register, Deploy, and Monitor to exercise the smallest sufficient local platform.
Primary sources
Checked 2026-10-15: NIST Cloud Computing Standards Roadmap, FinOps Framework, Google SRE on embracing risk, and CNCF Cloud Native Maturity Model.