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.

We design websites and products that make AI companies more money.

Siddarth Ponangi

Founder, Studio Maydit

We design websites and products that make AI companies more money.

Web and product design for AI companies

We help AI companies build fast, clean, and conversion-focused websites and products.

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

Table of Contents
Scroll to view headings
0%