There’s a crucial moment in platform engineering projects when you decide it’s ready to ship. For large projects (say, more than 1 year of engineering effort), it can be a difficult decision for the team. More cautious contributors want to delay for further testing and polishing. Other teammates inevitably begin to shift their attention to their next project, and are eager to move on.

I’ve found a simple criteria for navigating the risk/reward trade-off for launching a complex project:

Ship when the project is an improvement on the status quo.

If current engineering risks make it uncertain that it’s an improvement, continue testing and fixing defects until it’s clearly an improvement.

And all those extra features on the backlog: you can still build them, but it’s not worth withholding the value you’ve already created while you do so.

I’ve found this to be particularly useful for architecture migrations or component rewrites where achieving ‘feature parity’ with a deprecated implementation or ‘feature completeness’ of our ideal product is difficult or not worth the opportunity cost. Agreeing to ship a feature when it’s a net improvement over the existing solution ensures our team delivers value as quickly as possible, and helps us focus our effort on the most impactful work.