The MVP can be a complete spaghetti piece of crap, just make it work. When it works, you can iterate on making it elegant.
Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask.
Otherwise the spaghetti crap will end up in production.
My 2 cents only, and if you can make it work that's great. But I will never go ahead and recommend this to juniors or even younger seniors.
That said, TDD (with emphasis on driven) is no silver bullet either, especially when working that way - the tests are equally affected and I've seen enouph code bases where the initial test surface was so off compared to what was needed/sensible that it ended up being solely a hindrance and stifling to actual rework/refactor - with people ending up throwing it away and rewriting the tests from scratch, or worst case, simply setting them to be ignored on build.
1. Make it work
2. Make it right
3. Make it performant (if too slow).1. Make it work 2. Make it performant (always, but within reason) 3. Clean up your mess to prevent future mistakes
I claim that "if too slow" can't be judged because you almost never have the slowest possible target device.
Make it work. Then make it maintainable. Then polish it to make it more ideal.
When it works it can be spaghetti and lack testing and filled with hacks. After you make it maintainable it can still be less than ideal — some hacks here and there in leaf functions but things are localized and understandable and non-brittle (ie good testing coverage, design which has appropriate abstraction, refactors to promote test ability, no more spaghetti etc etc). Then in the final step you polish the stuff to gold (ie use better solutions or improve performance). It is the only way.
1. Make it work
2. Make it understandable
3. Make it performant (if too slow).I would if I could, but schedules are schedules and stuff has to ship...