I can completely understand the idea of building a quick MVP to validate the market.
But it's worth asking yourself: what happens if this works? I've never seen a company start to get traction and then put everything on pause to rewrite the app. There's no time.
Build your MVP with the expectation that it's actually a v1 that will need to be extended and maintained for years to come.
If you're wrong, you'll cost yourself a little time, but if you're right, you'll have saved yourself potentially years of carrying costs on crappy code.
Most of the time when we think of technical debt, it's in the context of making a trade-off between "Doing It Right" and "Getting Shit Done". That's certainly one form, but there's another type that's more insidious.
Read on...
With The Time Bomb, though, you probably didn't think about any of that, so when it does show up, it comes as a complete surprise. And unless you've got good monitoring and instrumentation, tracking down the root cause becomes a nightmare.
The takeaways here?
Document your assumptions.
Build in some form of monitoring early - at least in production.
And remember - technical debt isn't always about cutting corners. Sometimes it's about the system environment not turning out to be what you thought it would.
My 17-year-old this morning:
"Let's say we agree to disagree."
Me:
"No, I agree THAT we disagree, but I'm right and you're wrong. There's a difference."
People are willing to put up with a hell of a lot of bad UI and UX if you're solving a painful or expensive problem for them.
This doesn't give a free pass to developers who can't be bothered about the application front-end. Just understand that it might not be the main thing.