The cheaper opening move may carry a different ending
Build and licence proposals can support a sensible choice without supporting a simple savings claim. The differences need to survive approval.
A build-or-license paper can become misleading without containing a single incorrect price. One column describes an internal development programme; another describes a licence and integration work. Subtracting the smaller number from the larger produces an attractive benefit. Yet the two routes may leave the company with different rights, capabilities, dependencies and future costs. I do not need them to be identical before making a choice. I do need the recommendation to preserve the differences, so the decision-maker understands what the lower initial commitment buys and what it leaves for another day.
Our engine review compared a proposed ₹9.6 crore internal build over twenty-four months with a three-year licence costing ₹2.4 crore and ₹3.1 crore of integration work. The board selected the licensed route following management's recommendation. I supported it, but did not describe the ₹4.1 crore numerical gap as a demonstrated saving. An internally developed capability and a time-bounded right to use another party's technology are not the same asset. The useful strategic question was which commitment better served this programme, given its purpose, timing and the dependencies the company could accept.
## Name what each option leaves you owning
An internal build can create control over development, but it also leaves the company responsible for maintaining the capability. The initial estimate should not be mistaken for the complete cost of ownership. Skills, documentation, support and future compatibility may all matter. A licence may provide access sooner, but the rights depend on its terms and the company still has to integrate and operate the result within its product. I want the proposal to describe those obligations in ordinary language. A list of prices is easier to compare, but it may omit the very differences that should determine the decision.
The technical team examined what the licensed engine could do within the intended programme and what integration required. Legal colleagues reviewed the permitted use and commercial conditions, while finance examined the cash commitments. Strategy's contribution was to connect those views into a choice the chief executive and directors could assess. I would not ask a technical demonstration to settle a licensing question or a legal permission to establish that the capability would meet the product's needs. Each source answers part of the decision. The recommendation becomes stronger when the interfaces between those answers are visible rather than assumed.
Ownership also concerns what the business can change later. A company may want to extend a feature, support another deployment or use a capability in a different product. The selected route may allow some changes and require fresh terms for others. That is not necessarily a defect. It becomes a problem when the initial approval is remembered as permission for every future use. We retained the boundaries of the decision in the strategy record, so a later team could see why the route had been chosen and when it needed to ask a new question instead of borrowing the original approval.
## Make the next decision visible now
A three-year licence creates a future discussion even when the current programme is well founded. Renewal terms, the product's direction and the cost of changing route may look different by then. The proposal should identify that decision without pretending to forecast every detail. I want an owner and enough lead time to examine alternatives before the business becomes dependent on an urgent renewal. This is part of choosing the licence responsibly. It does not require predicting that the relationship will fail or treating every supplier as a threat; it requires acknowledging that a time-bounded right has a boundary.
The internal-build route also has future decisions. A twenty-four-month plan will encounter evidence about capability, cost and the needs of the product. It should not receive unlimited authority simply because the company would own the result. If the original rationale changes, management needs a way to reconsider the programme. In both routes, the useful discipline is to say what would cause a return to the decision-maker. That might be a material change in use, cost, timing or dependency. The point is not to write a condition for every minor variation, but to preserve the choices that remain strategically significant.
I supported the licensed option because its bounded initial commitment suited our programme and the documented dependencies were acceptable. That was a judgement under stated conditions, not a general preference for buying rather than building. Another product might require control the licence could not provide, or an internal capability might be important to the company's broader direction. Strategy should resist turning one sensible choice into a rule that saves future teams the trouble of examining their own circumstances. A precedent is useful when it helps someone ask better questions, not when it supplies an answer detached from the reason it was originally valid.
## Keep the comparison alive after approval
Once a route is approved, the organisation tends to simplify its history. The selected option becomes the obvious answer, and the rejected alternative disappears from view. I prefer to retain enough of the comparison to understand the trade-off later. If integration costs change or a new use is proposed, the original alternatives may help explain which assumption has moved. That does not mean reopening the whole decision whenever someone is dissatisfied. It means giving the team a record of the reasoning, so a review can distinguish a predictable implementation issue from a genuine change in the strategic case.
The benefit account should remain equally careful. We could report the approved ₹5.5 crore initial licence-and-integration commitment and the conditions attached to it. We could not report delivery improvements before implementation had demonstrated them, or present the difference from the build estimate as a realised financial result. A programme can be approved for good reasons without immediately producing a quantified benefit. Finance should help define how later outcomes will be assessed. That protects both the business and the team from a story that looks successful at approval but cannot be reconciled with what actually happened.
For a board, the key question is whether management understands the dependency it is choosing and has authority proportionate to that choice. Directors should be able to explain the broad difference between the routes, the reason for the recommendation and the circumstances that would require reconsideration. They do not need to select the engine or negotiate every technical term. They should also challenge an apparent savings claim when the comparison combines different rights or periods. A lower opening cost can be a sound reason to choose a route, but it should not obscure the obligations that make the decision consequential.
I would make the next comparison begin with the future the company needs, then examine credible ways to reach it. Prices and schedules remain essential, but they belong beside ownership, capability and the next decision the organisation will have to make. In our case, the licensed route was a deliberate commitment with a known boundary. Preserving that boundary made the recommendation clearer, even though it removed the simplest headline benefit. The company gained a choice it could understand and revisit, which is more useful than a savings number that depends on treating two different futures as though they were the same.