I always write "front-to-back". I write the code that uses a module, abstraction, api, etc. Then I write that layer until the code works. This goes on layer to layer.

To make it not become a tour-de-force, I start with a golden path, then various aspects (validation, additional operations on data besides rendering, etc). If the data doesn't exist yet, it's mocked. Then later, it's implemented (or made 'live') according to the mocked "schema".

It's not exactly TDD (I rarely write a test except for integration tests or the occasional "let's make sure it's not off-by-one"). It's not top down either, exactly. Perhaps you could call it "needs driven development" or "user driven development". You need it from the start and you use it as soon as possible. From then on, it's just improvements.

If you work back-to-front, you won't have anything working until late in the game. You're constantly imagining all the non-consequential "what-ifs".

But in a way, front-to-back is like TDD except you're not testing via unit tests. You're testing by using. And you will be using it so much that it will be tested thoroughly. You iterate continuously while the top layer / front end keeps working.

Sure, there can be an overarching design. There can be an architecture. There should be. But after that, it's about slowly molding the system towards that design. If you have understood the design, you know when you're veering off course. For sure, it's not like building a bridge.