I rarely doubt an experienced engineering team's ability to build a routine component. That confidence can make a build-versus-buy discussion harder, because capability becomes an emotional argument for ownership. The team sees a problem it knows how to solve, and the organisation mistakes that knowledge for a sufficient reason to solve it internally. My responsibility is to widen the account. I want to know what the component contributes to the product, what the team would otherwise work on and which obligations each route creates. A purchased option also deserves challenge. Paying a supplier changes the work; it does not remove the need to understand or govern it.
Capability is not the same as a reason to build
The strongest case for internal ownership usually concerns a capability that matters directly to how the product serves its users. It may require unusually close integration with domain behaviour, a pace of change a supplier cannot support or a form of control essential to the service. Those are propositions to examine, not phrases to attach to any feature the team prefers to build. I ask product and engineering leaders to describe a concrete consequence of not owning the implementation. If the answer is simply that external code feels less comfortable, we have identified a preference rather than completed the investment case.
There are equally weak arguments for purchase. A demonstration may make a component appear ready when integration, operating support and contractual review remain substantial. A first-year quotation may exclude usage growth or an important capability. A supplier can satisfy a checklist without fitting the way the product actually works. I therefore want the purchased route tested against the same defined needs as the internal proposal. The exercise should include the difficult interactions and the ordinary support tasks, not only the path the demonstration makes attractive. Engineers need a serious role in that assessment, even when the eventual decision is to buy.
Our scheduling choice illustrated the distinction. The internal proposal assigned eight engineers for nine months before continuing maintenance. The purchased route required four engineers for four months of integration, CNY 2.4 million of programme expenditure and CNY 3 million in annual licence charges. Four colleagues from the original proposed team worked instead on domain workflows. I supported that route because we judged those workflows more consequential to the product. I did not claim that the company suddenly needed four fewer people. The decision concerned where employed engineers would direct their attention, with a new recurring cash obligation attached to the component we chose to purchase.
Compare obligations over a common period
A comparison becomes misleading when one side contains only a first build and the other contains several years of fees. It is just as misleading when the internal estimate includes continuing staff but the supplier quotation omits support and integration. I prefer an ownership account over an agreed period, with the assumptions stated separately. For an internal build that may include implementation, examination, operating support, later adaptation and the effect of staff movement. For purchase it may include integration, licence or usage charges, supplier management, internal support and a credible account of changing the component later. Uncertainty should remain visible rather than be hidden inside an apparently precise total.
The period itself needs a reason. A short-lived experiment may not justify the same account as a component embedded in a product expected to serve clients for years. Finance can help establish a comparable basis without pretending to know every future cost. Product leaders can explain the changes they reasonably expect. Engineers can identify the work needed under those changes. The aim is not to produce a spreadsheet that makes judgement unnecessary. It is to prevent different time horizons and omitted obligations from quietly deciding the result before the meeting begins. The decision should survive a change in the presentation format.
Attention is difficult to price, but that does not make it irrelevant. The seventy-two planned engineer-months in our internal proposal and sixteen in the integration plan represented different schedules and different work. Subtracting them did not produce an invoice the company could avoid. The team remained part of the business, and the purchased component still required care. What changed was the opportunity to work on domain behaviour sooner. That opportunity needed its own plan and later evidence. A statement that engineers were freed is incomplete until the organisation can explain what they were asked to do and whether that work actually advanced.
I also resist presenting every unchosen build as waste. Building can develop knowledge and control that become valuable later, even when the first-year cost is higher. Buying can create a useful dependency whose terms later become less attractive. An honest account describes the benefits each route gives up. In the scheduling decision, we accepted recurring supplier dependence and retained integration responsibility in exchange for a smaller initial engineering allocation to a routine function. That exchange was defensible in its product context. It would not automatically be defensible for another component, another client commitment or a different company strategy.
Keep the choice reversible enough to revisit
An exit plan deserves more than a sentence in an approval paper. We demonstrated export and re-import of the scheduling state in a controlled rehearsal. That showed that one important body of information could move through a defined route. It did not establish that a replacement supplier would be available, that every behaviour would transfer unchanged or that switching would be cheap. I wanted the evidence stated at that level because exaggerated reversibility can make a dependency look smaller than it is. The team should know what has actually been tried and which parts of a later change remain assumptions.
Reversibility also has a cost. Maintaining an abstraction solely to imagine future replacement can complicate today's product. Preparing every possible alternative would consume the attention the purchase was meant to preserve. I look for a proportionate boundary: enough control over product behaviour, data and operating knowledge that the organisation can make a future decision without starting from complete dependence. That boundary should reflect the importance of the component and the likely difficulty of change. It is a design judgement, not a universal instruction to surround every supplier with the same layers of internal code.
The ownership account should return at meaningful points, such as a material product change or licence renewal. The original decision should not become a test of the CTO's consistency. If the reasons change, the preferred route may change too. My own improvement would be to establish the common multi-year account before either a build estimate or supplier quotation becomes the anchor for discussion. Engineering attention is one of the company's limited resources. Treating it explicitly helps the organisation reserve internal ownership for work with a convincing reason to deserve it, while accepting the responsibilities that remain when a capable supplier provides the rest.