A team estimates that building an in-house feature-flagging system will take six engineer-weeks, versus paying a SaaS feature-flag vendor a few thousand dollars a month. Why is comparing 'six engineer-weeks' to the monthly subscription price the wrong comparison, and what should be compared instead?

## Why the usual comparison fails Build-vs-buy cost comparisons fail most often because they compare a one-time number (build effort) against a recurring number (subscription cost) without normalizing the time horizon or accounting for what happens after launch. The correct comparison requires two additional concepts: 1. **total cost of ownership (TCO)** 2. **opportunity cost** ## Total cost of ownership TCO is the sum of every cost a system generates across its useful life, not just the cost to bring it into existence. For an in-house feature-flagging system, TCO includes the initial build, then ongoing costs every subsequent year: - **on-call response** when the flag service has an incident during a critical rollout - **security patching** as dependencies age - **feature work** to keep pace with what the team actually needs (targeting rules, percentage rollouts, audit logs, SDKs for every language the company uses) - **the cost of onboarding new engineers** to a bespoke internal tool with no external documentation or Stack Overflow answers None of this shows up in the initial six-week estimate, yet it is real spend that recurs every year the system is in production. Industry experience with internally built infrastructure tooling (queueing systems, feature flags, internal admin panels) repeatedly shows that ongoing maintenance cost across three to five years is several times the initial build cost, because the initial build only has to reach 'works for the demo,' while production operation has to reach 'works reliably under every edge case the business throws at it, forever.' ## Opportunity cost **Opportunity cost** is the value forgone by using engineers on this project instead of the next-best alternative. If the six-week build pulls two senior engineers off the core product roadmap, the real cost is not their salary for six weeks -- it is whatever feature, bug fix, or performance improvement those two engineers would otherwise have shipped, weighted by its value to the business. Because most engineering organizations are capacity-constrained (there is always more valuable work than people to do it), this forgone alternative is rarely zero, and for capabilities that are commodity rather than differentiating, it is almost never worth paying. ## The trade-off The trade-off is not simply 'buying is always cheaper.' Buying introduces its own recurring costs: - **subscription fees** that scale with usage or seats and can grow faster than a fixed engineering cost would have - **integration effort** to wire the vendor's SDK into every service - **switching cost** if the vendor's pricing or product direction later becomes unacceptable But for a genuinely commodity capability like feature flagging -- which several mature, well-funded vendors already sell as a polished product with SDKs across languages, audit trails, and enterprise support -- the vendor's fixed cost is spread across thousands of customers, so even a monthly fee that looks large in isolation is usually far below the fully-loaded cost of building and then indefinitely operating an equivalent in-house system. ## The failure mode in practice The failure mode this miscomparison produces in practice is a familiar one: a team greenlights the in-house build because 'it's only six weeks,' ships it, and then eighteen months later that system has become a load-bearing piece of infrastructure with no dedicated owner, an accumulating backlog of feature requests, and an on-call rotation nobody signed up for, while the original six-week estimate has been dwarfed many times over by unplanned maintenance work -- work that was never budgeted because it was never counted as part of the original decision. This is sometimes visible in postmortems where an incident traces back to 'our internal tool for X' rather than a named, supported vendor product, and the fix requires pulling engineers off planned work yet again. ## A concrete illustration **A concrete illustration.** a fifty-engineer company estimates six engineer-weeks (roughly $15,000-$25,000 in fully loaded cost) to build feature flagging, against a SaaS vendor charging $2,000 per month ($24,000/year). On the surface the build looks cheaper. Once TCO is added -- say, four engineer-weeks per year of ongoing maintenance and feature work, plus one engineer-week per year of on-call/incident time, both at the same fully loaded rate -- the in-house system costs roughly $12,500-$21,000 every year after the first, quickly exceeding the vendor subscription, before counting the opportunity cost of what those maintenance hours could otherwise have produced. This is why mature engineering organizations default to buying commodity infrastructure tooling and reserve in-house builds for capabilities where the differentiation value clearly outweighs a multi-year TCO plus opportunity-cost comparison.