I can tell a story about a company that missed out on opportunity _because_ they didn’t rewrite early enough. A friend of mine worked for a business that had a

I can tell a story about a company that missed out on opportunity _because_ they didn’t rewrite early enough. A friend of mine worked for a business that had a product that was supposed to be built to a specification provided by a regulatory body, but fundamentally hadn’t been. The product team was bogged down firefighting regulator requests, chronically hacking in modifications (on modifications) to give the appearance that it was built to spec, but it fundamentally wasn’t - stemming from core design choices. There was almost zero product velocity and changes regularly failed. After years, it burnt out one team and got handed to a fresh team, dropping most of the gained experience on the floor. The opportunity cost of those fundamental design decisions had been extremely high - years spent covering up mistakes, rather than addressing them at the root - because it was quicker/easier/preferable. The result was that every patch to get them over the latest regulatory hurdle had hardened the software which, by the end, was so brittle that enhancing the product was impractical. The business survived. The product sucked. The team hated the experience. It’s a sad, yet familiar story. What’s the alternative? Refactor, and re-factor often. You could always be refactoring (rewriting) toward deeper insight. As you gain experience in a domain, you could ducktape new requirements on (for a higher future cost), or you could use your insights to better design your software (for a higher now cost). It depends on whether you would like your software to remain responsive to change. A primary quality of software is its changeability. I recommend keeping your software responsive to change.