I couldn’t disagree more. TDD makes it possible to ship a more reliable product without superfluous code. TDD also makes it possible to move more quickly without breaking things. That “fast-paced creative process” turns into an albatross when your new stuff is breaking the old. The VC types are the ones that can actually forgo TDD because you can simply hire a lot of QA. When you are trying to ship “fast,” TDD reduces QA time and also ensures that your developers aren’t breaking each other’s work. I have hired by plenty of test-optional companies and they struggle with adding features or wonder why their application slows to a crawl with even a few hundred users — yet without tests fixing those problems results in new development grinding to a halt.

In XP parlance, a spike is specifically to allow for rapid development of a feature idea, but your entire development process ought not be a spike or it will bite you in the ass much sooner than you think and at a point where you can least afford it: when you have some mild, but not strong traction and churning users from buggy code is a real problem.

Unless you have some viral-type product (like Facebook,) move fast and break things is a terrible strategy if you care about creating a sustainable business.

Make it work, make it scale, make it elegant is smart advice, but part of “make it work” means that it doesn’t break. I would argue that pure TDD isn’t necessary, but I would adamantly suggest that shipping code without tests is far more risky than just hoping you catch issues when clicking through the application. Whether you write tests first or code first, that isn’t the issue — as long as you have tests before you ship. If you fail enough times with building a business, that’s the first thing you’ll learn.