Many programmers who begin TDD have the same concern as you. Many of them find that over time they're more productive over the long haul with TDD. It takes a little while to arrive at that realization.
However, writing detailed tests up front would completely destroy my "flow" when implementing features in a web application. It would certainly take me more time because there is going to be a large increase in the amount of code to write.
I simply don't have the time available to do this. I get a few weeks to knock out an application and then I'm on to the next thing!
In my experience, even if you are building a quick'n'dirty prototype, you'll always need to fire up a terminal or run the GUI to interact/play with the prototype you are building, to see if it "works".
In this case you may apply a --this is my very own definition-- "lightweight TDD approach" just to automate all the procedures that you normally do to test your prototype. Moreover, since you are writing a test for something that does not exist, it may help you defining better what you want from your experimental code, because you are using your prototype before it even exists :)
The massive upside is that there is much less defects in the end product (think it was 50-80% in the study, but can't recall exactly).
Depending on the project, the extra time needed, might or might not be worth it.
Take a somewhat complex web app, that is used for a marketing campaign. It has a life time of only 2 months. In this case it does not make sense to use TDD, as the lower defect rate and "future-proofing" qualities, might very well not be worth an increased budget.
As a counter example, I'm working with a company that uses TDD for their current development, but employees work on a platform with little test coverage. As a consequence of lacking unit tests, they're only able to release a few versions each year because their manual testing burden is so high (estimated by one manager as about half of the cost of a release). They've found that TDD for their new features doesn't escalate the QA cost as significantly as not doing it. Bottom line: it's a little more time up front, but they've found it to be a long-term gain.