[deathanatos]

Then launch that MVP into production, and never be given an ounce of time by your PM to fix any of the shortcomings that you thought were not part of "Do the Simplest Thing". Iterate on that principle for new features, too: what's the simplest way to get this new feature out? And this one?

And then find yourself surrounded by tech debt an a system that was cobbled together, not designed.

[int0x2e]

This is a very common case, sadly. But this is due to people failing to use MVPs correctly. Instead of being a tool for the sole purpose of rapid learning and iteration, it is used to falsely accelerate delivery. When done well, you build a series of prototypes/MVPs with the sole purpose of learning faster what customers really need. You should then put all your effort into building that really, really, well, and kill off anything that didn't work out. Ideally, you should always have new, minimalist code for new features you are exploring, and lots of old, extremely well designed, implemented and well-tested code for all the areas you already know are critical for your users - and nothing in between (no "nice to have" features, no failed experiments that linger on and contribute to your tech debt...)

This takes a ton of discipline, but in my experience the only alternatives are to either build up a ton of tech debt, or build things extremely well from day 1, only to end up dying due to low velocity (even if you get some critical decisions spot on in the beginning, no PM or engineering team that I've ever seen has been able to make only good decisions over several years...).

[layer8]

I think “simplest” needs to be applied to the whole system, not just to the change at hand. If you keep the system overall as simple as what could possibly work overall, you’re probably already reducing tech debt. Tech debt usually implies that things are getting unnecessarily complicated (accidental vs. essential complexity).