A team is deciding whether to keep using a managed service or bring it in-house. What trigger should govern the decision, and what asymmetry usually settles it?

The trigger

A number defined in advance, not a feeling. For example: this service now costs more than two fully-loaded engineers · its latency is now a product problem measured against a stated budget · we have exceeded the tier where the pricing model works · a capability we now need is not on their roadmap.

Reviewing against a defined trigger prevents both failure modes: the premature migration driven by a general sense that we could do it better, and the indefinite acceptance of a bill that stopped making sense two years ago.

The comparison that must be honest

Licence cost versus fully-loaded engineering cost, not licence versus zero. Operating a database, a streaming platform or a search cluster well requires engineers, and their cost plus the opportunity cost of what they would otherwise have built is the real alternative.

For a small team, one engineer exceeds most managed-service bills, which settles it immediately in one direction.

The factors beyond the two numbers

• Whether it is differentiating. Operating a database well is difficult, valuable, and not what customers pay for.
• Who handles the 3am failure. A managed outage is outside your control and usually shorter than yours would have been; a self-hosted one depends on whether the person who understands it is reachable. Control is not the same as capability.
• Exit cost, always higher than estimated — which argues for keeping provider-specific features at the edges regardless of the decision.

The asymmetry that usually settles it

Buying is more cheaply reversible than building. A team that bought and now needs to self-host has a working system to migrate and knows exactly what it needs. A team that built and now wants to buy has an integration project, a decommissioning project, and skills invested in the wrong place.

The genuine counter-case

If your product is infrastructure, operating infrastructure is your competitive competence, and buying it means buying your competitor's constraints. That is a real exception and it applies to fewer organisations than claim it.