Rescuing the Vibe-Coded MVP: An Agency Audit for AI-Built Products

A new kind of client is showing up: "We built our MVP with AI tools, it's live, and now it's a mess." The founder used a prototyping tool or a coding agent to get to market fast, which was a reasonable choice. Six months later every screen looks slightly different, half the error states are missing, the Arabic version is broken, and nobody on the team is sure how it all fits together.

NN/g calls this the new "big ball of mud": when building is cheap, systems grow faster than anyone's understanding of them. Here's the audit I'd run before agreeing to fix one of these products, and how to decide between refactoring and starting over.

The new client type

These founders aren't careless. They used the tools available to test an idea quickly, and often it worked: they have users and maybe revenue. The problem is that every feature was generated separately, so the product has five button styles, three date pickers and no shared logic for errors. Each new feature makes it worse, because the agent copies whatever pattern it finds nearby.

They don't need a prettier UI. They need structure.

A 5-part audit

1. Components

Screenshot every screen and group similar elements: buttons, inputs, cards, modals, lists. Count the variations. If there are seven button styles where there should be three, write that down. This inventory becomes the basis for the design system.

2. States

AI-built screens usually show the happy path only. For each key screen, check empty, loading, error, partial data, offline and permission states. Missing states are often the biggest source of support tickets.

3. Flows

Walk through the main tasks as a new user: sign up, the core action, payment, settings. Note dead ends, duplicated paths and steps that only make sense to the person who built them.

4. RTL and localization

If the product supports Arabic, switch to it and repeat the flow walk. Typical problems: hard-coded left/right spacing, icons that don't mirror (or mirror when they shouldn't), mixed-direction text in the wrong order, and English strings that were never translated.

5. Accessibility

Check color contrast, tap target sizes, focus order, form labels and screen reader names on the main flows. Generated UIs often look fine and are hard to use with anything other than a mouse or a finger.

[Waleed: add an anonymized summary from a real rescue audit, e.g. counts of component variations or missing states.]

Pulling a design system out of an existing product

Don't start a rescue with a redesign. Start by turning what exists into a system:

1. From the component inventory, pick the best version of each component and make it the standard.
2. Extract the colors, type sizes and spacing actually in use, then reduce them to a small set of tokens.
3. Build those components in Figma with all their states and with RTL support.
4. Write short usage rules, so the next feature, whether built by a developer or an agent, uses the system instead of inventing something new.

The users already know the current product. A system that keeps what works and cleans up the rest is less disruptive than a new look.

Refactor or rebuild?

Refactor when the main flows make sense and users can complete their tasks, but the surface is inconsistent. Fix components, add states, apply the system screen by screen.

Rebuild when the flows themselves are wrong: the product structure doesn't match how users think, core features are in the wrong place, or every fix breaks something else. Then the existing product is research, not a base.

A quick test: if fixing the top five usability problems mostly means changing components and copy, refactor. If it means moving features between screens and rethinking navigation, rebuild.

Pricing and scoping rescue projects

Don't quote a rescue project from a demo call. You can't see the mess until you're inside it. I'd scope it in two steps:

1. A paid audit covering the five areas above, ending in a prioritized list of problems and a refactor-or-rebuild recommendation.
2. A fixed-scope fix based on the audit: design system extraction, then the highest-impact flows first.

The audit protects both sides. The client gets a clear picture even if they don't continue, and you don't commit to a price before you know what you're fixing.

See it in real projects

Design system work across mobile apps and dashboards is part of most projects in my portfolio. If you're earlier in the process, read how to design an MVP or my SaaS dashboard design rules.

Sources: The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile (NN/g), Workflow lab: Deploying designs directly with Figma Make (Figma), Why Your Website Should Never Stop Changing (Smashing Magazine).

FAQs