[jmount]

Okay now the less sarcastic- but equally harsh answer. If you think test driven development is not good you should not use it. If you think test driven development is good and you don't use it on your minimally viable product: then you are signaling that even you don't find the product interesting enough to even automatically exercise.

[ZeroMinx]

I disagree. I like TDD, but if you're quickly building a MVP that has beforehand been decided(1) to be thrown away once you've gotten funding, just hack it like you've never hacked something before. You're aiming to prove a concept, to visually display your idea.

(1 - do make sure the non-technical people in the group really really really understand this)

[jmount]

Interesting. I still come out on the other side. If the product isn't being used much and might be the basis of pivot/re-factor, then tests become even more valuable. Better to catch the bug in a test than in your first demo.

[ZeroMinx]

I think it very much depends on what your MVP is, what your goal with it is.

My stance here is where the goal of the MVP is to get investment money. You're not showing your MVP to random users. You want to build something that "works" quickly, then get money to build it "properly". You have a good idea and you want to attack a certain market; but, you don't want to spend year(s) building a product and hope you can grow slowly. Your aim is to prove to investors that; you're a good team, you have a solid concept, with money you will gather a team and build this product.

In this case, I think you can(/should?!) skimp on the unit tests. The code will be thrown away after a few months of its inception.

There are of course many different MVP situations, this is just one small avenue.