A founder in London shipped his B2B product in 9 days with an AI builder. No designer, no agency, no Figma. He got 740 signups from 1 launch post. 31 of them created something. 4 of them came back in week 2. He wrote to me with 1 sentence: "The app works, so why does nobody use it."
I opened the product and it took 6 minutes to see the shape of it. Every screen was a card grid. The 3 most important actions had the same visual weight as "Export as CSV". The dashboard showed 8 metrics, and the 1 number the user actually cares about was 5th from the left. There were 14 button variants in a product with 11 screens. There was no empty state, so a new account saw a table with headers and nothing under them, which reads as broken. The product was not ugly. It was undecided.
This is the most common brief I receive in 2026, and I want to be clear at the start: the tools are good, and I use them. What follows is where they stop, how to tell whether you have reached that point, and what a designer changes when you have already shipped.
What AI builders are genuinely good at now
I do not want to argue against tools I open every day. In 2026 an AI builder will give you a working product with authentication, a database, a table, a form, a settings page and a deploy in a few days. It uses a decent component library, the spacing is consistent, and nothing looks like 2013.
For a founder this replaces 3 things that used to cost real money: the first clickable version, the internal tool nobody wanted to pay a designer for, and the 20 small screens around the core feature. If you are testing whether anybody wants the thing at all, build it this way. I tell founders this in intro calls and I lose work by saying it.
What the tools do not do is decide. They will build whatever you describe, at the same quality and the same weight, forever. Design is mostly deciding what matters more than something else, and that decision needs to come from outside the generator.
The 7 problems I find in almost every AI built product
I have audited 20 or so of these in the last year. The findings repeat with unusual consistency.
1. No hierarchy
Every card, every button and every metric carries the same weight, because each was generated in its own prompt without the others in view. The user opens a screen and does not know where to look first. This is the single biggest reason an AI built product feels generic.
2. The interface mirrors the database
Every field in the table becomes a column, every table becomes a page, every relation becomes a tab. It is a readable structure for the person who wrote the schema and a maze for a new user who thinks in tasks, not in entities.
3. Structure does not survive real data
The dashboard works with 4 projects and collapses at 400. Nobody generated the filter, the sort, the pagination, the search or the bulk action, because in the prompt there were 4 rows.
4. States are missing
Empty, loading, error, permission denied, expired trial, no results after a filter. AI builders produce the happy path with sample data. In the products I audit, 60 to 80 percent of states are undesigned, and the empty state is the first thing a new user sees.
5. Copy is filler
"Welcome back", "Manage your items", "Something went wrong". In a SaaS product the copy is the interface. Generated microcopy is grammatically perfect and says nothing about your domain, which is why the product feels like 100 other products.
6. The component set drifted
14 button variants, 3 modal patterns, 5 spacing scales, 2 date formats. Each prompt was locally consistent and globally not. This is what makes shipping feature 12 slower than feature 3, and it is the part founders feel as "the code got messy" without seeing that it started in the interface.
7. Nobody designed the first 5 minutes
There is a signup, and then the product. No first run, no sample data, no path to 1 real result. The activation moment was never defined, so the product cannot lead anyone to it. In the case above, that alone explained most of the 4 percent.
Under all 7 sits the same cause. The tool generated screens 1 at a time, and nobody made a decision that applied to all of them.
When to bring in a product designer
Not on day 1. Design before there is evidence is expensive guessing, and an AI builder is a faster way to produce the guess. 2 of following 4 signals are enough.
People sign up and do not activate
You have traffic and the number that is broken is between signup and first real result. This is a structure and onboarding problem, and no amount of regeneration finds it, because the tool does not know what your activation moment is.
You are about to charge money
The pricing page, the plan limits, the upgrade moment and the billing states are the flows where trust is decided. These are also the flows AI builders generate most poorly, because they are full of edge cases and legal copy.
You are selling to companies, not consumers
The first enterprise buyer will look at permissions, roles, audit trails, empty states, error handling and accessibility. A generated product usually has none of these designed, and this is where deals stall.
Shipping is getting slower
When a new feature takes 3 times longer than the same feature 2 months ago, and the reason is that nobody knows which button, which modal and which spacing to use, you have a design system problem. The fix is 1 week of consolidation, not more prompts.
The inverse is also true. If you have 30 users and no clear signal, do not hire me. Talk to 10 of them, change the product with your builder, and come back when the question is why people are not using it rather than whether they want it.
What we do to an AI built product in 2 weeks
This is the engagement I run most often now. It is deliberately small, because the product already exists and the job is to decide, not to redraw.
Days 1 to 3: audit and structure
I use the product as a new user on a real device, read the analytics if they exist, and write down every screen, every state that is missing and every decision that was never made. I come back with 1 page: what the product is for, who it is for, and the 1 action that matters most on each screen. This is the same method as our UX audit for SaaS products, compressed.
Days 4 to 6: hierarchy pass
The 3 or 4 screens that carry the product get redesigned properly: 1 primary action per screen, a real information hierarchy, the numbers that matter made large and the rest made secondary or removed. Most of the perceived quality jump happens here.
Days 7 to 9: component consolidation
14 buttons become 3. 1 spacing scale, 1 type scale, 1 set of tokens, in Figma and in your Tailwind or component config so your builder keeps using them. After this, the next thing you generate looks like the product instead of like a new product.
Days 10 to 12: states and copy
Empty, loading, error, no results, no permission, limit reached, trial expired. Real copy in your domain language, written for each one. This is the least exciting part of the work and the part that changes how finished a product feels.
Days 13 to 14: first run and handover
The first 5 minutes designed on purpose: what a new account sees, sample data or a guided first object, and the path to 1 real result. Then handover, which for a founder building with AI tools means something different from a normal design handoff to developers: a Figma file, the tokens in your config, and a written spec per screen you can paste into your builder as context.
That last point matters. I do not want to become the bottleneck in a workflow whose whole value is speed. The deliverable is a system and a set of decisions you can keep building with alone.
Mistakes I see founders make with AI built products
Regenerating instead of deciding
The 6th version of the dashboard has the same problem as the 1st, because the prompt never said which number matters most. A better prompt cannot contain a decision you have not made.
Buying a visual refresh
A new colour, a new font, a landing page. The product still has no hierarchy and no states, and in 3 weeks it feels the same. The visible symptom is style. The cause is structure.
Waiting for the rebuild
"We will design it properly when we rewrite it in month 6." The users you are losing now are the ones who would have told you what to build in month 6.
Skipping the component consolidation because it is invisible
It is the cheapest week in the whole engagement and the one that compounds. Everything you generate afterwards inherits it.
Assuming the tool handled accessibility
Generated components often have reasonable markup and then lose it in customisation: focus removed, contrast below 4.5:1, modals without focus traps, icon buttons without names. If you are selling to enterprise or in the EU, this shows up in procurement.
FAQ
Do I still need a product designer if I build with AI tools?
For the first working version, often not. You need one when the numbers stop moving: signups that do not activate, a pricing flow you are about to charge money through, enterprise buyers asking about roles and states, or shipping that is getting slower because the component set drifted. The designer is buying decisions and structure, not screens.
Why does my AI generated app look generic?
Because each screen was generated separately with no hierarchy applied across them, the layout mirrors your database rather than the user's task, and the copy is filler. Fixing 1 primary action per screen, a single type and spacing scale, and domain specific copy removes most of the sameness in about 1 week.
Can you work with a product built in Lovable, Claude, Codex, v0, Bolt or Cursor?
Yes. We deliver Figma or Claude Design plus the tokens and component decisions in your config, and a written spec per screen you can paste into your builder as context, so you keep shipping without us in the loop.
How long does it take to redesign an AI built MVP?
Our pass covering hierarchy, component consolidation, states and first run is 2 weeks. An audit with a prioritised list is 3 to 5 days. A full redesign with a design system is 4 to 6 weeks.
Should I rebuild the product before hiring a designer?
No. Design against what exists, then rebuild if the code requires it. The decisions we make in the 2 week pass are the input to a rebuild, and making them first means the rebuild happens once.
What do you actually deliver at the end?
A Figma file or Claude design prototype with the core screens and every state, a token and component set in your config, real copy for empty, loading and error states, a designed first run, and a 1 page spec per screen written so your AI builder can use it as context.
Working with us
We work with founders who shipped something real with AI tools and hit the ceiling of what generation alone can decide. The usual engagement is 2 weeks: audit and structure, a hierarchy pass on the core screens, component consolidation into 1 system, every missing state designed with real copy, and a first run that takes a new user to 1 real result.
We are honest about when to wait. Under 100 users and no clear signal, spend the money on talking to users instead. If your only problem is that the landing page looks weak, that is 1 week of work, not a redesign. If your product is already consistent and the issue is 1 flow, we quote the flow.
If you built it yourself and it works but nobody stays, send us the link. Book a free 15 minute intro call and we will walk through the first 5 minutes of your product with you and tell you what we would change first.
