Why Your First AI-Built App Should Be Ugly

The first time someone uses an AI app builder, they usually do one of two things. They either accept the first thing the AI gives them and ship it, or they spend three days getting the buttons to be exactly the right shade of indigo before they’ve tested whether anyone actually wants the thing.

The second group is much more common, and it’s a more expensive mistake. This post is about why your first AI-built app should be a little ugly on purpose.

The polish trap

There’s a particular feeling that hits about ten minutes into building something. The basic flow works. A user can sign up, do the thing, see the result.

And then your eye catches on the spacing. The headline is too big. The empty state has placeholder text. The login screen looks like a login screen from 2008.

You ask the AI app builder to fix the spacing. It does. Now the button is in the wrong place. You ask it to fix that. It does. Now the modal animation feels weird on mobile. You spend the next two hours nudging things one pixel at a time.

The problem isn’t that polish is bad. Polish is great — eventually. The problem is that polish is the most measurable kind of progress. It’s visible. It feels like work. And it’s almost completely uncorrelated with whether your app is good.

When your app is a little ugly, you stay focused on what it does. When your app is pretty, you start treating it like it’s done.

The thing you actually need to know

You’re not building an app. You’re testing an assumption.

The assumption usually looks like: people who have problem X will use a tool that does Y to fix it. Everything else — the colors, the typography, the empty-state illustrations, the onboarding tour — exists to serve that assumption. If the assumption is wrong, none of that polish matters. If the assumption is right, you have plenty of time to fix the colors later.

A friend of mine spent two weeks last month building a habit tracker. Not the world’s most original idea, but he had a specific take on it: track habits in groups of three, and the groups expire weekly. The AI builder gave him a working prototype in about an hour. He spent the rest of the two weeks making it pretty.

When he finally showed it to people, the feedback was: “I like it, but I’d never use three at a time.” His core assumption was wrong. The pretty version was wrong in exactly the same way the ugly version was wrong. He just spent ten extra days polishing a wrong answer.

What “ugly enough” looks like

Ugly doesn’t mean broken. It means deliberately under-decorated. Some markers of an app that’s at the right level of ugly for a first build:

The default theme is doing most of the visual work. If the AI builder shipped with reasonable defaults, you haven’t touched them yet.
Empty states are plain text. No illustrations, no “Looks like there’s nothing here yet 🎉” copy. Just “No items.”
The favicon is the default. Same with the logo, if there is one. A wordmark in a default font is enough.
The auth flow is whatever the builder gave you. Not branded. Not custom. Functional.
One page can be wired up to do the real thing. Everything else can be a stub or a link to a Google Form.

If you stare at your build and feel slightly embarrassed showing it to a friend, you’re probably in the right zone. That embarrassment is useful — it pushes you to talk about what the app does rather than what it looks like. Which is the conversation you actually need to have.

The two kinds of feedback ugly gets you

When you show someone a polished app, they react to the polish. “Oh, the gradient is nice.” “I like the icon.” None of that is information. It’s the conversational equivalent of small talk.

When you show someone an ugly app, you get two different kinds of feedback, both useful:

“This solves a real problem for me.” This is what you came for. If the ugly app gets this reaction, the assumption holds, and you have license to polish. Now the colors matter, because you’re not gambling on the colors carrying a bad idea.
“I don’t really see what this is for.” This is also what you came for, even though it stings. The ugly app surfaces this faster because there’s nothing distracting from the core thing. A pretty app would have gotten a polite nod and a “looks cool” and you’d have learned nothing.

Both reactions tell you what to do next. The polished version would have given you opinions about font weight.

”But what if I want to show investors / clients / my mom?”

Reasonable concern. Three things help.

The first is that “showing investors” is usually further away than it feels. Most people who say “I need this to look good to show investors” don’t actually have an investor meeting on the calendar. They have a vague future investor and a very real present anxiety. The vague future investor would much rather see a working product with five real users than a polished mockup with none.

The second is that there’s a difference between ugly and unfinished. An ugly app can still feel intentional — flat colors, system fonts, consistent spacing. What you want to avoid is half-decorated: a beautifully animated landing page in front of a settings screen that’s still showing Lorem Ipsum, or three different button styles because you customized two of them and forgot the third. That kind of unevenness reads as “I gave up partway through,” which is much worse than “I haven’t started designing yet.”

The third is that ugly-on-purpose is a genre. Plain-text indie tools, brutalist design, the “made by one person” aesthetic — these are widely respected looks. If you’re worried about looking unprofessional, lean into the look on purpose rather than apologizing for it.

When polish becomes the right move

There’s a point where ugly stops being useful. It’s not a specific date — it’s a specific feeling. You’ll know polish is the right move when:

You have a small number of real users who keep coming back.
You stop hearing “I don’t see what this is for” and start hearing “I wish it did X.”
You’re embarrassed by the app in a way that’s specifically about how it looks, not how it works.
Friction in the UI is causing actual drop-off, not just bothering you aesthetically.

When you hit that, ask the AI builder to give you a design pass. Pick a typeface. Tighten the spacing. Polish the empty states. The work you do then is rewarded, because each pixel of polish lands on top of something that already works.

Before you hit that, polish is mostly procrastination wearing the clothes of progress.

The version of this advice you can use today

Open your AI app builder and look at whatever you’re working on. Ask yourself a single question: if I gave this to one real person tomorrow, would I learn something I don’t already know?

If yes, you don’t need to polish. You need to send it.

If no, the gap isn’t usually that the app is too ugly. The gap is usually that the core flow doesn’t do anything yet — it has a homepage and a login and three almost-functional screens, and the thing it was supposed to do is still TODO. That’s the part to build next. Not the colors.

Your first AI-built app is supposed to be ugly. It’s supposed to look like a draft. That’s how you can tell it’s still moving.

If you’re earlier in the process, you might like what your first AI-built app should be or how to describe what you want to an AI builder.