Clearly Design

Prototype-first • AI-readable system • No rewrite by default

Built it with Lovable, Cursor, Bolt or v0? Make it look like a real product, without a rewrite

You shipped a working SaaS or AI product with AI coding tools. We redesign it on the code you have—tokens, real components, the states the tools skipped—and leave rules your tools follow next time.

Book a Discovery CallWhat We Include

The code that works is the valuable part. What usually needs replacing is the interface layer on top: hardcoded colors, near-duplicate components, screens that never got empty or error states, and a product that drifts every time someone prompts a new feature.

We redesign on the code you already have. We prototype the new direction on your real product first, then ship a token system, consolidated components, the states the tools skipped, and your most-used screens. We leave behind rules—tokens, component specs, DESIGN.md—that Cursor, Claude Code, Lovable or v0 can read as constraints, so the next feature does not undo the work.

Below is who this is for (and who it is not), what we keep versus replace, what the engagement includes, and when you should fix engineering before you touch UI.

Who this is for (and who it isn't)

This is for you if: you have a live or demo-ready SaaS or AI product built mostly with AI coding tools; it works; users, buyers or investors are judging it; and every new feature makes the UI feel more generated, not more intentional.

Go somewhere else if:

Why it looks like AI made it (and why prompting harder doesn't fix it)

Every generation is a fresh guess at "a nice app." Without a system to follow, the tool falls back on defaults: familiar font, familiar accent color, radius and spacing that change per screen, three button styles where one would do, and screens that only exist for the happy path.

The tool is not wrong. It has nothing stable to follow. Fix the thing it follows—tokens, component specs, documented patterns—and the same tool cleans up quickly. Keep prompting without that layer and you get another slightly different average.

That is the same drift craft and standing out when everyone has the same tools describes from the buyer's side, and what we write about in how we structure design systems for AI. This page is the engagement; those links are the how-to.

Redesign vs rewrite: what we keep, what we replace

KeepReplace
Data model and business logic that worksHardcoded colors and spacing → semantic tokens
Routes and integrations that are stableNear-duplicate components → one canonical set with variants
Features users already depend onHappy-path-only screens → designed empty, loading, error, and permission states
Auth and billing flows that are correct (even if ugly)Per-screen one-offs → shared layout and hierarchy patterns
The repo as the source of truthGeneric visual hierarchy → clear decisions about what matters on each screen

We only touch code where the redesign touches it. We are not sweeping the codebase for sport.

What the redesign includes

Order matters. This is how we run it:

  1. Review the live product — We click through like a new user, list what drifts, and agree what changes first and what stays. If the foundation needs engineering first, we say so before design work starts. A pre-redesign audit helps when the team cannot yet say what is load-bearing.

  2. Prototype the direction on your real screens — We try options as working interactions, not static comps, and keep what feels right. That is prototype-first discovery on the product you already have.

  3. Tokens — One color scale with semantic names, one type scale, one spacing scale, radius, shadow; hardcoded values become token references. See design tokens and Tailwind v4 for how we think about the file shape.

  4. Components — Collapse near-duplicates into one set with documented variants. See component specs for AI.

  5. States the tools skipped — Empty, loading, error, permission-denied, long content, first run. When design and code disagree, we document the resolution: when the design system and code disagree and design specs from code.

  6. Your 3–5 most-used screens — Dashboard, onboarding, settings, the core workflow: made to feel like one product, not a pile of generations.

  7. Rules your AI tools follow — DESIGN.md, tokens, component specs, and rules your Cursor, Claude Code, Lovable or v0 setup reads as constraints, plus a short note on how to prompt against the system. Start with DESIGN.md, Claude Code design skills, and AI-ready design systems part 7.

  8. Apply it — Component by component, either your team and your AI tools with our specs, or with us on the design-build subscription.

The core system and key screens come first. The rest is applied screen by screen while you keep shipping. Scope depends on your product, so we price it after the product review.

How we keep the next AI feature from undoing it

Drift comes back unless something holds the line.

The system lives in files the tools read. Tokens, component specs, and DESIGN.md are not buried in a PDF. They are constraints the next prompt inherits.

Raw values get flagged. When a new screen hardcodes #6366f1 again, someone notices—not six months later when the product has fourteen greys.

Someone owns review. That is the partner part. Clearly stays on via the design-partner subscription to review new features against the system, extend components when a flow needs something new, and keep marketing and product UI aligned if both surfaces ship fast.

If you only want the system layer without the screen redesign, that is design systems for AI teams. This page is the full product pass.

When a redesign is the wrong call

Be honest with yourself (we will be honest in the review):

  • Auth or session bugs that leak users across accounts
  • Payments that double-charge or fail silently
  • Data exposed, unbacked up, or impossible to reason about
  • A repo that will not build or deploy reliably
  • Every change breaks two unrelated things

Those are engineering problems. Fix them first—often through finishing partner Track 2 or an MVP rebuild—then redesign the interface on a foundation that can carry it.

Proof (what we can say today)

Here's how the same method played out on a real product.

Modernizing an Established Property CRM with AI, One Working Prototype at a Time
Product DesignDesign Systems

Product Redesign + AI

6 weeks

Real Estate Technology

Modernizing an Established Property CRM with AI, One Working Prototype at a Time

Nekst.com

An established property CRM with a large customer base needed to modernize dated screens and layer in AI. Changing a live product this size is expensive to get wrong, and static mockups couldn't show how it would actually feel.

Timeline

6 weeks

From first concept to a dev-ready product direction

Approach

Prototype-first

Decisions made on real behavior, not static mockups

Output

AI-ready design system

A style guide the team and AI tools extend from one source of truth

Nekst is an established property CRM, not a vibe-coded side project. We modernized it without a risky rewrite, prototype-first, and ended with an AI-ready style guide the team and their tools could extend from one source of truth—then handed execution to their engineering team. That is the same sequence we use here: real product, working interactions, system that outlasts the engagement.

"From start to finish, Francois and his team are able to deliver a well thought out, expertly designed and well built product in such a short amount of time. His team takes care of a lot of the little details and just knows the right way to build software. Highly recommended!"

— Brett Keppler, Founder of Nekst

For the how-to behind the system files, see the AI-ready design systems series and design system audit when the library is already the mess.

How it works with Clearly (and what it costs)

Discovery call — You share the link, stack, and what "good enough to show" means for you.

Product review — We click through, flag drift and missing states, and tell you if engineering has to come first.

Prototype, system, and key screens — Direction on the real product, then tokens, components, states, rules, and your highest-traffic flows.

Apply and keep going — Roll the system through the rest of the product while you ship. Ongoing delivery runs on the design-partner subscription—not a one-off sprint and goodbye.

Confirm live plans on homepage pricing before you buy. Pause or cancel.

Standard, $4,995/mo. One workstream at a time. Async, with weekly progress. Prototype-first discovery. Slack and Looms. Framer and Webflow where relevant; product UI in the stack you already use.

Advanced, $7,495/mo. Two workstreams. Check-ins as needed. Engineering integration. Custom React and Tailwind components. Prototype-to-production translation when your team needs it.

That is the same subscription shape as product design subscription for B2B SaaS.

Related

FAQ

Send us the link to what you built

Book a discovery call and walk us through the product. We'll tell you honestly whether a redesign on your current code is the right move—or whether engineering has to come first.

Book a Discovery Call