only in job interviews, in blog posts, when commenting in HN or answering stackoverflow questions, and only when I have a budget to do so. In other cases, I just try to write self debugging code (assert things, think of edge cases, good logging, never take anything for granted). e.g. I test the code within the code. instead of writing an external test, my test code is within the code, not sure if it makes sense, but that's how I get to do things both fast, and keep quality.
HOWEVER, if I have unit tests available, this is priceless, so if I can have the budget and time to write them, I would, but if writing tests would mean you avoid writing code, just write code (unless you work for SpaceX or NASA)
And to your point, if it's an MVP? I would say ditch the tests at first, it's better to test your idea and market, than test code that might be thrown away. and you should plan to throw away your MVP. you won't be able to live with yourself if you don't. just call it garbage code, and if you get traction, just rewrite the whole thing. it might be a lie your are telling yourself, but if you over engineer your startup, you might end up not knowing if it's true or not.