Reading time:
7 min read
Last updated:
Fix or Rebuild an AI MVP: The Four Signals
Fix or rebuild an AI MVP? Rebuild if the data model, permissions, core loop or code safety is wrong. If not, a cleanup of a few weeks is usually enough.
Clean up an AI MVP when it does the right job and people simply struggle to use it. Rebuild it when the base is wrong: the data model does not match how customers work, login and permissions were added late, the main loop is not the one users want, or nobody can change the code without breaking something. If none of those four is true, a cleanup of a few weeks usually beats a rebuild of a few months.
You built the first version fast with tools like Cursor, Lovable, or Claude. It works. People sign up. Then they get lost or leave after one try. Starting again is tempting. First, work out which kind of broken you have.
Two kinds of broken
Works but feels broken can mean two very different things. The first is a surface problem. Buttons look different on every screen. Labels use words only your team knows. The product does the right job, but a stranger cannot follow it.
The second is a foundation problem. The product looks rough because the structure under it fights every change. Each fix creates a new bug. Each new feature needs a workaround. The rough edges are a symptom, not the cause.
A cleanup fixes the first kind. It cannot fix the second. The four signals below tell them apart.
Signal one: the data model is wrong
The data model is how your product stores things and how those things connect. A common case: the first version assumed one person owns everything. Now customers want teams, shared folders, or more than one workspace. If adding that means changing how every record is saved, the model is wrong.
You can spot this without reading code. Ask your developer how long a small change would take, such as letting two people see the same project. If the answer is weeks, and the reason is how the data is stored, no amount of screen design will help.
Signal two: auth and permissions were bolted on
AI tools are good at making a login screen. They are less reliable at deciding who can see what. In many fast builds, access gets checked in some places and not others. One user can reach another user's data by changing a link. Admin actions hide behind a secret button instead of a real rule.
This is a trust problem, and trust is hard to win back after a leak. If access rules live in scattered spots, plan to rebuild at least that layer, and have an engineer review it before any design spend.
Signal three: the core loop is not the one users want
The core loop is the thing people come back to do. Your MVP was built around your best guess. Sometimes users show you a different loop. You built a chat tool, and they only use the export. You built a dashboard, and they only read the weekly email.
If people keep using the product in a way it was not built for, you are not looking at a cleanup. You are looking at a new product that shares some code with the old one. Cleaning up the old loop would only make the wrong thing easier to use.
Signal four: nobody can change it safely
This is the plainest signal. The person who built it has left, or most of the code was generated and nobody fully understands it. There are no tests. Every release is a guess.
A cleanup is a long series of small changes, so a product nobody can change safely cannot be cleaned up. If this signal shows up with any of the other three, rebuild. If it shows up alone, a short engineering pass to add tests and simplify the worst files can be enough to make a cleanup possible.
What a cleanup pass actually involves
A cleanup keeps your code, your data, and your users. It changes what people see and how they move through the product. For most early products it takes a few weeks, not months.
It starts with a walk through every flow. Signup, the first visit, the main task, settings, and what happens when something fails. The output is a list of where people get confused or stuck, ranked by how much each one hurts.
Then come the fixes. Buttons, inputs, cards, and spacing get pulled into one small set of parts, so every screen looks like one team made it. Empty screens get a clear first step. Labels move from your team's words to your customer's words. Error states say what happened and what to do next. Mobile layouts get fixed.
It ends with handover. Clean design files, notes on what changed, and a short list of risks that are still open, so your developers can keep building without losing the thread.
What to keep from the first version
Even if you rebuild, the first version is not wasted. Keep what users taught you. Which features they used, which they ignored, and the words they used to describe the product. That is your real spec.
Keep the prompts and model settings that work. That testing work carries over to any new codebase.
Keep the flows that already work. If one path reliably gets people to a result, copy its order and its steps, even if you redraw every screen.
And keep your users' accounts and data. Plan the move before anyone writes new code, so nobody has to sign up twice or loses their work.
A simple way to decide this week
Sit down with whoever writes your code and go through the four signals. Answer each one yes or no, with a real example from the product. If all four are no, clean it up. If one or two are yes, fix those parts in the code and clean up the rest. If three or four are yes, rebuild, and carry over what you learned.
Decide on what you see in the product, not on how tired you are of it. A rebuild feels like a fresh start, but it means months where users wait.
Where to go next
If you are not sure yet where users get stuck, start with what a UX audit actually finds before you pick either path. If the answer is a rebuild and money is tight, MVP design on a small budget explains what a fixed price can cover. If the answer is a cleanup, our AI MVP cleanup service is built for exactly this kind of product.
Studio Maydit is a web and product design studio for AI founders in the US, the UK, and Europe. We design products and build in Framer, Webflow, or custom code, and we have worked with teams such as Wave, PixelFlow, and Mi-VAD. For Dualite, design work supporting a repositioned ICP helped the product reach 100,000+ users in seven months. If your AI MVP works and still feels broken, and you want a straight answer on cleanup or rebuild, book a 30 minute call and walk us through it.
Frequently Asked Questions
Continue Reading

ChatGPT Is Introducing Ads. Here’s the UX Risk Nobody Is Talking About
As ChatGPT prepares to introduce ads, most conversations focus on revenue and scale. But the bigger question is how monetization reshapes user trust, cognitive flow, and product intent. This Studio Notes piece explores the hidden UX risks product teams should pay close attention to.

Siddarth Ponangi

Why designing for power users too early breaks SaaS products
Many SaaS products become difficult to use not because they lack features, but because they introduce complexity before users are ready for it. Designing for power users too early often feels like progress, but it quietly undermines adoption for everyone else.

Siddarth Ponangi

Why second-use experience matters more than first impressions in SaaS
Many SaaS products spend enormous effort optimizing first impressions. What often gets overlooked is what happens when users come back for the second time, which is usually where real adoption either starts or quietly falls apart.

Siddarth Ponangi

