I start by looking for related use cases that could be folded into the project. Then I design the UI. Then the architecture. Then finally, and with lowest prio

I start by looking for related use cases that could be folded into the project. Then I design the UI. Then the architecture. Then finally, and with lowest priority and least amount of effort, the code. I never do proofs of concept or throwaways or tests, because you can't test a whole architecture except by building it. And I really don't care if each individual function is beautiful and perfect, it just has to be as good as I can get it without taking time away from unit tests, edge case handling, architecture, etc. If the code is bad, I'll refactor it, if it's mediocre, I'll refactor it later, but I'm not going to rewrite and try to port over all the dozens of edge case handlers I've probably added, unless the whole thing is truly horrendous. It is very messy and ugly to try to adapt something to have a UI with a completely different model under the hood, so I start with UI and workflow.