I spent a couple months building antihq/fuse.

It looked nice. Modals that eased in with smooth animations. Empty states with illustrations. Support text for every form field. Subheadings that contextualized every page.

I did ship it.

But it was half-done.

I polished before the app was functionally complete. I ran out of steam and left it incomplete.

This is the trap.

The conventional wisdom in software development is that polish matters. That users won't use ugly apps. That you need great UX before you can ship. That frontend work is part of building an MVP.

I believed this for years.

Then I had a moment where everything changed.

I was months into building antihq/fuse, adding polish to pages and interactivity, when I realized something: I was spending all my energy on frontend work while the app still wasn't complete. I'd lost my momentum.

I had a choice: keep polishing, or step back and focus on functionality.

I chose the wrong path first. I kept polishing. The app shipped, but it shipped incomplete.

That's when it hit me: polish first isn't just wasteful. It's a trap that guarantees you'll ship half-baked work.

I'm rewriting antihq/fuse now with a different approach.

1. Decision fatigue is real

Every UI decision you make is energy you're not spending on functionality.

Do I use a modal or inline editing? Do I need an empty state here? What should the confirmation text say? How should I style this button?

These seem like small decisions. They compound. By the time you've designed your tenth screen, you've made hundreds of decisions. Your brain is tired. The energy you should be spending on understanding the problem and solving it? Gone.

When you remove the decisions, you free your brain to focus on what actually matters. No modals, no empty states, no supporting text. Just making the app work.

This is the subtle trap.

When you polish first, you invest time in the frontend. That investment becomes a wasted cost. When you realize the architecture is wrong, you can't pivot without feeling like you're throwing away work.

So you don't pivot. You ship something half-baked. Or worse: you never ship at all.

Low-fidelity removes wasted effort. When everything is bare-bones, changing the architecture is easy. You haven't invested in UI patterns you'll need to discard.

Most projects don't die because people can't start. They die because people can't finish.

Starting is exciting. Everything is possible. The vision is clear.

Finishing is grinding. The excitement fades. The bugs pile up.

If you add polish work to the middle of that grind, you make finishing harder. You increase the surface area of what you need to complete before you can launch.

Low-fidelity removes the obstacles to finishing. When there are no modals to design, no empty states to craft, no micro-interactions to perfect, the path to done is shorter.

So what does low-fidelity look like in practice?

For my current project, I'm following simple rules:

The goal is to be in a phase where I can change anything at any time. Where I'm free to pivot architecture without frontend debt. Where I can focus entirely on functionality before I spend a single thought on how it looks.

I'm rewriting antihq/fuse this way right now. No polish until the app is complete.

It's okay to ship ugly apps.

It's okay if your confirmations are browser alerts. It's okay if your forms have no descriptions. It's okay if there are no charming illustrations when data is empty.

Users don't care about polish nearly as much as you think they do. They care about solving their problem.

Finish > polished.

Every time.

The apps that change the world aren't the ones with the best UX. They're the ones that exist.

Ship something ugly. Make it work. Then, if you want, make it beautiful.

But first, finish.