Why every AI-built app looks the same

Where the sameness comes from

Open five apps built with AI tools this year and you will see the same screen five times: a white page, a dark primary button with softly rounded corners, cards with a one-pixel border and a faint shadow, a sidebar, four stat tiles across the top. That is not a coincidence. It is what happens when every tool starts from the same parts and nobody changes the defaults.

There are four layers to it.

The same component kit

v0's documentation says it uses shadcn/ui as its default component system, and that the model is trained on the default implementations of those components. Plenty of other React and Tailwind code follows the same conventions, so a lot of AI output, whichever tool wrote it, ends up with a components/ui folder full of the same Button, Card, Input and Dialog files.

That is a sensible choice. shadcn/ui describes its own defaults as carefully chosen and designed to work well together, and they do. But a kit designed to look good with zero changes will look identical across every product that makes zero changes.

The same theme values

The shadcn/ui default neutral theme sets --radius to 0.625rem (10px), a near-black primary of oklch(0.205 0 0) and greys with no hue at all. In the new-york style, the Card component ships with rounded-xl border shadow-sm and py-6, and the default Button is h-9, text-sm, font-medium. Tailwind's own default font-sans is a system font stack, so unless something sets a typeface, the app renders in whatever the operating system provides.

Put those together and you get the house style of 2025 and 2026: neutral, rounded, small and quiet. It is fine. It is also everywhere.

The same layouts

Ask any model for "a SaaS dashboard" and you get a sidebar, a row of stat cards, a chart and a "recent activity" table. Ask for "a landing page" and you get a centred headline, a two-button hero, three feature cards with icons, a logo strip, testimonials and a pricing table.

A language model produces the most likely answer to a prompt. The most likely dashboard is the average dashboard. So the layout you get back is a blend of thousands of products, none of which were yours.

The same decoration

When a prompt asks for something "modern" or "beautiful", the models reach for the same decoration: a purple-to-blue gradient, glowing blobs behind the hero, emoji in headings, icons in tinted circles, gradient text, a "New" badge with a sparkle. These are the visual equivalent of filler words. They signal effort without saying anything about the product.

The tells, and what each one is hiding

Each of these is a default standing in for a decision. The fix is to make the decision.

Tell	Where it comes from	The decision it skipped
Purple-to-blue gradient header	A common response to "modern" in the prompt	What colour belongs to this brand, and where it should appear
Emoji in headings and labels	The model filling space with personality	What the label needs to say, in plain words
Four identical stat cards	The average dashboard	Which one number matters most to this user today
Icons in tinted circles	Template sites and UI kits	Whether an icon adds meaning, or just fills a slot
Everything centred	Landing page conventions applied to app screens	Where the eye should start and where it should go next
Same radius on everything	One --radius value, never changed	What shape language suits the product
Lorem-style copy ("Streamline your workflow")	No real content in the prompt	What the product does, for whom, in one sentence
System font	Tailwind's default font-sans	What the product should sound like when read

None of these is wrong on its own. A single accent gradient can be lovely. The problem is that they arrive together, unchosen, and users have seen the set many times before.

Why it matters once real users arrive

For a prototype, none of this matters. You are testing whether anyone wants the thing, and AI tools are brilliant at getting a clickable version in front of people in a day. I use them for exactly that.

It starts to matter at three points.

1. When you ask for money. A generic interface reads as a weekend project. People hesitate to put card details into something that looks like a template.
2. When you are compared. A buyer looking at three tools in three tabs will remember the one that looked like it knew its job. If all three look the same, they remember none.
3. When the defaults start fighting the product. A finance tool needs dense tables and tabular numbers. A booking app needs a calendar that fits on a phone. Default spacing and default cards suit neither.

There is a quieter cost too. Generic layouts often hide the product's real job. Four stat cards of equal weight tell the user that nothing is more important than anything else, which is rarely true. I go through the most common of these in UX mistakes AI tools make in every app.

What the tools are doing about it

The builders know about this, and they are adding ways to steer the look. That is worth using before you change any code.

• Lovable now asks design questions about colour, typography and layout before it builds, unless your prompt already sets a clear direction or the request is purely functional, such as a standard dashboard. Its docs say it derives spacing, corner radius and animation intensity from your answers, and you can save fonts, colours and style keywords to the project's instructions so later prompts stay consistent.
• v0 lets you connect your own design system sources, such as a repository, Figma frames and docs, so generations draw on your components rather than the defaults.

These help. They do not replace the judgement about what goes where and why, which is the bit that makes a product feel designed. A good palette on the average dashboard is still the average dashboard.

How to break the pattern

You do not need a rebrand. Most of the sameness lives in a few files, so a few decisions change every screen.

1. Pick a typeface on purpose. One family for the interface, maybe a second for headings. Load it with next/font and wire it into the theme. This does more for character than anything else on this list.
2. Change the shape. Set --radius to something that suits the product: tighter for a data tool, softer for a consumer app. Then check cards, inputs and buttons still feel like a family.
3. Choose one accent and spend it carefully. One brand colour, used for the primary action and active states. Everything else stays neutral. Delete the gradients.
4. Set a density. Decide whether this is a calm, spacious product or a dense working tool, and adjust type size and padding to match. Default text-sm on default padding is neither.
5. Write real content. Real labels, real numbers, real empty states. Placeholder copy makes every product sound the same.
6. Design the layout around the main job. Ask what the user opens this screen to do, make that the biggest thing, and demote or remove the rest.

The code for steps 1 to 3 is in how to make a shadcn app not look like shadcn. If you want those decisions to hold as the app grows, building a design system for your MVP shows how to keep them in one place.

When to get a designer involved

You can get a long way with the list above. Where a designer earns their fee is in the layout and flow decisions: which screens exist, what each one is for, what the user sees first. That is the part an AI tool cannot infer from a prompt, because it depends on who your users are and what they are trying to get done.

I am a product designer who also writes the code, so I make those decisions and implement them in the same pass, often in the same Next.js codebase the AI tool started. You can see how that played out on FindPopups, a marketplace I designed and built end to end for a client. For the wider picture, the design guide for AI-built apps covers every part of this in one place, and what a designer who codes actually does explains how the work is split.