If I'm optimizing for my brain, my strengths, and my programming style, bottom up is better. With a particular focus on nailing down the hardest or murkiest part, then the next hardest/murkiest, and so on. This phase can be ugly code if that helps ... the point is to uncover unknowns and let points with the fewest degrees of freedom become the first stakes in the ground.

When there are no particularly hard/murky parts left, it's top-down from there, and that let's you choose the approach for various portions of the solution (such as, this part will be pure functions, this part will be based around an arena allocation, etc.).

Even though I mentioned both bottom-up and top-down, the 10,000 foot summary is bottom-up, because it starts there and the most time is spent in that mode.

Whenever I get away from that and go top down too early, I'm likely to run into some area that either gets reworked, or that I compromise on and _wish_ I could justify the time to rework it.

(And also with the caveat that some things are simple enough you could do them any way you want, and those are good candidates for top-down, which also seems more comfortable for more junior devs).

UPDATE: However, I completely agree with another commentor -- start with the UI first! I don't think that contradicts bottom-up ... it's about fleshing out both the requirements and the _potential_ requirements.