You don't rewrite for features. You rewrite for better maintainability and productivity. After your rewrite you shouldn't have to rewrite it again. The balancin

You don't rewrite for features. You rewrite for better maintainability and productivity. After your rewrite you shouldn't have to rewrite it again. The balancing act is that a rewrite should improve your implementation velocity, so while it may be a setback, your velocity should be much higher than your competitors, so over time you would be able to surpass them and then gain a lead they cannot beat thanks to your higher productivity. As the technical debt grows, your productivity will get slower and slower, so you won't be able to keep up with your competitors anyways. That's the gamble. Just because Facebook was written in PHP doesn't mean that the code was unmaintainable. I don't know if it was or not. The problem they had was that it was unscalable, and they didn't do nothing about it. They wrote a PHP to c compiler, and that's a monumental task. So they paid their technical debt in a different way that they decided was the most efficient way for them to deal with it. If the problem isn't scalability, and is maintainability, you may not have that luxury. Unmaintainable code's problem is inherently in its structure, and the only solution for that is refactorization or a rewrite. The code may be so unmaintainable that even refactorization isn't really possible. The best offense is a good defense. Deal with technical debt from the get go. Sure, write your MVP in a weekend just to test it, but rewrite it early for maintainability while it's still small and possible.