Opening the book…
Perfectionism disguises itself as high standards, but it's often just fear wearing a respectable outfit, and it costs us more than sloppiness does because it's socially rewarded and therefore rarely challenged. Shipping something good enough now, and improving it based on real feedback, almost always beats polishing something in private until it's perfect, because reality has information your imagination doesn't. The pursuit of perfect delays the moment you learn whether you're even building the right thing, and that delay is the actual expense, not the imperfection. This doesn't mean shipping junk; it means being honest about the difference between 'this needs to be better before it's safe to ship' and 'this could be marginally nicer and I'm scared to let go.' Most of the value in most work is captured well before the last polish, and the last polish often addresses problems no user will ever have. Good enough, shipped and learned from, is a strategy; perfect, delayed, is usually a comfort.
Define what 'good enough to ship' actually means for a given thing before you start, so you have a real finish line instead of an infinite one. Ship when you hit that bar, and let real usage tell you what actually needs improving rather than guessing in the polish phase. Ask whether more effort is buying real value or just soothing your discomfort with releasing something imperfect. Distinguish the polish that matters, the stuff users feel, from the polish that only you will ever notice, and spend accordingly. When you catch yourself gold-plating, stop and ship, then improve if the feedback warrants it. Treat 'done and out in the world' as usually more valuable than 'perfect and still on your machine.'
Some things genuinely need to be right before they ship, security, anything handling money, anything hard to reverse or that could hurt someone, and there 'good enough' has a much higher bar. The rule targets the vast middle of ordinary work, not the small set of things where a mistake is catastrophic.