Will you?
Are you sure?
Do you have data to back your supposition?
My contention would be that at the end of the day, the requirements of the interface to support unit testing will result in a very similar set of design choices, whether you write those tests up-front, as-you-go, or after-the-fact.
The only difference is that if you write them after-the-fact, you may push some amount of refactoring to the end of the process instead of doing it along the way.
But I'll bet you have about as much data as I do to back your beliefs. ;)
That's my experience. I started doing TDD more than 10 years ago, and it took me about a year to fully make the switch from test-after to test-first programming. I regularly try experiments with different personal code bases.
If you're arguing from personal experience, that your code ends up just the same either way, good for you. But I suspect you're arguing from theory here.
Getting the testing as close in time to the implementation as possible probably makes a bigger difference than first vs last.
However, for me that's a hard set of behaviors to stick to. If I let myself say, "Oh, I'll test that later" I'm likely to get lost in the problem, write bunch of production code, and then say, "Well, it already works, but I guess I'll add some tests." There's no clear stopping point.
Test-first programming, on the other hand, is easier for me to stick to. If I don't have a broken test, I write one. If I have made the test pass, it's time to write another test before I write more production code.
This is definitely not my experience. As Kent Beck says, TDD is a design technique. It forces you to always start thinking of the code from the outside of the unit. If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works.