Followup on previous thoughts.

When I speak of "Test-driven development," I'm usually thinking of unit tests and integration tests. I think building those out before you have a concrete implementation tends to be putting the cart before the horse. They're most useful as regression tests to make sure you haven't broken something important when you make changes in the future.

Test-driven development can be quite valuable for end-to-end tests if you can get the client to agree on what the software is supposed to do in the form of a walkthrough of the behavior. I still tend to put this alongside or slightly after the initial design (most clients I work with aren't abstract system thinkers, so it's real hard to get them to understand a design they can't see and touch), but getting the client to agree that their initial ask matches to a test script of the form "User goes to A, clicks B, enters C, should see D happen" is a form of test-driven development when you implement a program to satisfy that script.

... but I still tend to keep that script hand-written before wasting the cycles on automating it in code.