You should at least put a testing framework in place, and test some low-hanging fruit. That'll make it easier to get momentum going for more testing if things continue, and at least give you some minimal coverage.
And test at least fundamental parts of user interaction with the MVP: sign up, login/logoff, conversion funnel, what else depends of MVP. MVP may have limited set of features, but implemented ones should work.
This not TDD but rather BDD without unnecessary fluff.
Additionally manual testing is repetitive work. It is better to outsource it to the computer to make sure that testing is in fact done when needed - preferably after each code change. By doing testing this way is far easier to isolate immediate cause of failing test - developer knows what was changed recently.
And just as an anecdote, I built a prototype for a client that laid fallow for a couple of years while he worked on some parallel business ideas that I also built, but when it came time to return to fire up the original idea there had been major language and framework version upgrades in the meantime. I had to almost rebuild the app from scratch due to the lack of tests in the MVP that could tell me what was what. Basic tests would have cut the upgrade time in half. Not that I mind the billings, but this time and effort gets in the way of the bizdev.
This not TDD but rather BDD without unnecessary fluff.
Additionally manual testing is repetitive work. It is better to outsource it to the computer to make sure that testing is in fact done when needed - preferably after each code change. By doing testing this way is far easier to isolate immediate cause of failing test - developer knows what was changed recently.