The amount of time saved depends on a number of factors. Writing a test suite before you know what your product even does can be counter-productive.
I never write tests until something is launched and it looks like anyone will be using it. There's no need to have test coverage for software that's going to be completely torn to shreds every couple of weeks until that first spark lights in the eyes of a user who finds the value proposition you've been searching for.
Unless you have the luxury of working with a full team and have plenty of time to kill (read: money to burn) you're going to want to cut as many corners as possible. If it is a fast moving new market it could save valuable weeks to skip out on a number of 'best practices'. You would be astonished at the number of products launched without a stitch of what would pass muster on a more mature code base.
The goal is to find something that people want, not to make robust software. That comes later. Pretending like there aren't up front costs to writing and maintaining tests is absurd.
You'll also find that if you're sticking to functional and stateless design patterns that your code is incredibly easy to reason about. Ditch the OO patterns like observers... Anything where new instances of objects are created, anything where you can't literally serialize the state of your running application, restart it, and get back the entire state you were just in...
People tell me that tests force people to reason about their code in such a manner. I think that reasoning about your code in such a manner is the really important part. You end up with code that you never need to step through or pry apart in a REPL. It just works (TM). I dunno, I've been writing application code for almost 20 years now. I've learned from a lot of architectural and implementation mistakes I've made over the years. State and side effects are the fucking enemy. All of the testing in the world isn't going to fix your ill conceived understanding of whatever new problem space you're dealing with.
I also find tests make the most sense when there are multiple developers working on a code base. A single dev isn't going to benefit as much from the cost.
And yes, again, tests do have a cost. It is absolutely ridiculous to argue that they don't.
And ditch the objects. They make no sense outside of a Smalltalk or Self environment.
After you launch and people are using it, after you've got a few developers working in the code base, after the product has actually stabilized to a set of more or less concrete specifications, THEN write your tests.
If it really is the frontier then cowboy coding is just fine. :)
The west wasn't won with prudence, it was won by taking risks and moving quickly. You're not the only guy with dreams of building that railroad. Someone else is already driving stakes in to the ground. You can go back and build a better bridge, a more efficient path through that valley, or a safer incline AFTER the line links up. The intercontinental railroad was a mess for decades after it was built but that didn't matter because the utility provided was immeasurable.
If you're just building another commuter rail in a busy town, well then I can't relate at all. Use your TDD mumbo jumbo. I'm a start up guy, I'm a cowboy, ON A STEEL HORSE I RIDE. AND I'M WANTED, DEAD OR ALIVE.
BTW, I have plenty of start up friends who successfully start new projects with tests. I mainly wrote this because I wanted to quote Jon Bob Jovi at the end there. :P