Fantastically succinct market analysis and reality check.

Continuing the aside: Going short in 1998 would have been too soon, 2001 Q2 too late. Countless startups have flipped in the past few years after only a year or two of growth. There's ample time to build something valuable and flip it in the next few years. History repeats itself but that won't help us predict the market.

(I'd give bonus points for your Camus quote!)

petercooper has nailed it.

Disclaimer: I'm an agile evangelist, spent years at startups, and I love quality code.

Be pragmatic in your adoption of any software engineering process, agile methods included. Tossing TDD/BDD out the window because you believe it's slowing you down is a mistake. Adapt it to your environment; use the aspects that work.

Remember that the goal of TDD/BDD and testing in general is to deliver useful software that works. Even your startup's prototypes, quickly hacked together, should at some level meet that criteria.

If you're writing code, you have an intention for it, a purpose, and that can be tested on some level or another. It's hard to make an argument that manually clicking around in your browser after writing your implementation is superior to having some form of automated tests in place beforehand.

If you're in the exploratory stage of a startup, you'll pivot often, and you'll be building a lot of throwaway prototypes. You should limit the depth of your test coverage, but you can still do TDD. Just don't be strict about it. Not every method/class/behaviour needs to be tested. You may not know the broad direction your software is going in. When you sit down to code, at least the behaviour of that little piece is known, and it's at that point you can write a test or two to express and validate your intentions.