Two designs meet the requirement, one on components you could move anywhere and one on a proprietary managed capability — why might the harder-to-leave option still be right?

## Portability is a cost, not a virtue It is easy to argue for the option that is easiest to leave, because the argument sounds like prudence and costs nothing to make in a review. But portability is not free and it is not the objective. The objective is the system doing its job at an acceptable total cost, and "could be moved" is one input to that, competing with the others rather than outranking them. The two options in this question have costs of genuinely different shapes, which is why comparing them directly is the whole skill: | | Portable design | Proprietary managed design | |---|---|---| | Recurring cost | the work the managed capability would have done, the people who do it, and the capabilities declined to stay on the lowest common denominator | the price of the capability | | One-off exit cost | low | the rewrite, plus whatever data it accumulated | | When it is paid | every month, for as long as the system lives | once, and only if a move actually happens | | Certainty | certain | probabilistic | ## The comparison that decides it Stated plainly: compare the **recurring cost of staying portable, over the expected life of the design**, with the **exit cost, discounted by the probability you ever exit**, and add the value of what the capability actually does for you. 1. **Estimate the recurring side honestly.** It is not only the bill. It is the engineer-time to run the self-managed equivalent, the on-call burden it creates, and the features you decline because only one platform offers them — the lowest-common-denominator tax, which is invisible in a budget and very visible in a roadmap. 2. **Estimate the exit side as an inventory, not a fear.** What would this decision add to the code row, and what would it add to the data row? A capability that will accumulate years of data adds far more than one that holds transient state, even if both are equally proprietary. 3. **Put an honest probability on leaving.** Most systems are decommissioned on the platform they were built on. If the organisation has never moved anything and has no reason to, a low probability is the truthful input, and pretending otherwise just dresses a preference up as arithmetic. 4. **Say the assumptions out loud.** The numbers are invented; the assumptions are what the room can actually argue with. A decision recorded as "we accepted this much exit exposure because we valued this much recurring saving, assuming this lifespan" is reviewable later. "We chose the portable one to be safe" is not. ## Cap the exposure you could not afford Accepting lock-in knowingly is not the same as accepting it without limit. The useful discipline is to pick which of the four dimensions this decision is allowed to grow, and cap the rest: - **Keep the data extractable.** The data dimension is the one that grows every day without anyone deciding, so it is the one worth capping first: keep retention deliberate, and keep at least one path to the bytes that does not depend on the proprietary interface. - **Keep the commitment shorter than the architecture's expected life.** A term that outlives the design turns a reversible decision into an irreversible one on someone else's schedule. - **Keep the operational dependency from becoming one person's specialism.** A capability that exactly one engineer understands is an availability risk long before it is a portability one. - **Keep the code surface countable.** Not abstracted away — just known, so that the technical row of the inventory can be produced without a research project. ## When the portable option genuinely wins The reflex is wrong as a reflex, not as an answer. Reach for the portable design when there is a concrete reason the probability of moving is not low: a customer or regulatory requirement for a second source; credible doubt about the provider's willingness to keep the capability alive; a workload that must run somewhere the platform does not reach; or a commercial position where signing any term commitment is not acceptable. In those cases the recurring tax is buying something real, and it should be named as insurance with a premium rather than presented as good engineering hygiene. ## Saying it in a review The sentence that lands is roughly: *this option is harder to leave, here is the size of that exposure in the dimensions it grows, here is what we avoid paying every month by taking it, and here is when we look at it again.* That answer survives the follow-up question. "It is more portable" does not, because the first thing an experienced reviewer will ask is what that portability costs and what it is insuring against.