That's a great question.
My style is definitely to just start coding. When you are starting from scratch you have very little idea of what the requirements are. If you start building you will run into a lot of things very quickly and learn a lot.
Then, after you've spent some time building out something, you can step back and start thinking about proper abstractions. Here you probably don't want to code but want to outline boundaries and cut the system up into a few large subsystems. You basically go top-down, but only very shallow. Establish the basic architecture, but give room for all of the subsystem to breathe. Those subsystems could be implemented really messily, but be refactored completely later, and if the interfaces are built correctly the other subsystems would never know.
Redesigns need to be evaluated in light of how much money it's going to save the company down the road. You should almost never redesign an entire app. You are losing way too much gained knowledge and that investment will most likely not pay off. But if you have a good enough architecture, as explained above, you should never be forced to redesign an entire app. If you're app is so fundamentally flawed that you need to redo the entire thing, you're in trouble. Usually, you just need to redesign a subsystem, and if you really believe the new design is better, the company should support that because better code, if done within a realistic timeframe, will almost always pay itself back by reducing maintenance costs.