top of page

Design-to-Production Strategy: Integrating AI
& Moving Beyond Figma

Catchpoint

Figma, Cursor, and Lovable Logos

Executive Summary

The Shift

AI‑first, code‑native tools like Lovable, Cursor and other AI Design Tools are changing where and how UI is best designed. Instead of designing abstractions that are later rebuilt in code, these tools allow teams to design directly in production‑grade code, using real components, tokens, data, and APIs from the start.

The Problem with the Current Model

Our Figma‑first workflow (including Figma Make):

  • Treats design as an upstream abstraction

  • Requires translation into real components and systems

  • Produces prototypes that approximate behavior rather than exercising it

  • Relies on process and discipline to maintain consistency
     

Even with AI assistance, this model creates friction, rework, and loss of intent.

Why AI‑First Tools Are Structurally Different

AI‑first tools like Lovable and Cursor:

  • Generate UI inside real projects and repositories

  • Use actual production components and tokens

  • Support real data, APIs, and AI‑driven behavior in prototypes

  • Treat prototypes as branches of the production codebase
     

This places prototypes under production governance by default and removes an entire translation layer.

Design Systems: Governance Where It Matters

  • In Figma, design systems are visual representations that must be mirrored and enforced manually in code.

  • In Lovable, design systems are first‑class, code‑native projects whose rules are applied programmatically during generation.

This shifts consistency from review and documentation to enforcement by the system itself.

Strategic Direction

We should intentionally move away from a Figma‑first workflow toward an AI‑first, code‑native design model, with Lovable (or a similar tool) as the primary environment for prototyping and early implementation.

Figma should be repositioned as a supporting tool for exploration and ideation—not the system of record for UI definition or handoff.

This shift:

  • Reduces translation cost

  • Improves prototype fidelity

  • Strengthens design system enforcement

  • Accelerates delivery

The Problem We Are Experiencing

1. Design and Production Are Increasingly Decoupled

Today, our workflow still largely follows:

Design in Figma → Handoff → Rebuild in code
 

Even with Figma Make and MCP:

  • Design artifacts remain upstream abstractions

  • Generated code is rarely production-ready

  • Engineering still translates intent into real components and systems
     

This creates:

  • Rework and friction

  • Loss of design intent during implementation

  • Longer iteration cycles

2. AI Has Shifted Where UI Is Best Created

AI-first tools like Lovable allow teams to:

  • Generate real, running UI immediately

  • Iterate visually in code

  • Treat UI as a living system, not a static artifact
     

In these environments:

  • Layout, responsiveness, and behavior emerge directly from implementation

  • The feedback loop is faster and more concrete

  • The boundary between "prototype" and "product" is blurred
     

This makes frame-based, design-first tools less central than they once were.

3. Figma Make vs AI‑First Coding Tools: A Structural Difference

Figma Make is often positioned as Figma’s answer to AI‑first tools like Lovable. However, the difference between them is not feature‑level—it is architectural.

Figma Make is an AI feature inside a design tool.
Lovable is a design capability inside a code environment.

​

That distinction has real consequences.

​

Figma Make: Design‑Centric Code Generation

  • Make generates code from Figma artifacts (frames, components, variables)

  • Generated UI remains conceptually downstream of the design file

  • Components are references to Figma constructs, not production primitives

  • Iteration still flows: design → generate → adapt → integrate
     

As a result:

  • Code is rarely reused verbatim

  • Engineering must still reconcile generated output with real component APIs

  • Make works best for demos, scaffolds, or isolated surfaces—not sustained product development
     

AI‑First Tools (e.g., Lovable): Code‑Centric Design

  • UI is composed directly from real components and tokens

  • Prototypes are running applications

  • Design decisions are expressed as component composition, not visual approximation

  • Iteration happens in the same medium as production
     

This removes an entire translation layer rather than optimizing it.

4. Working Prototypes: Data, APIs, and Real Behavior

A critical distinction between AI-first tools and Figma Make is how close a prototype can get to real production behavior.
 

Lovable: Prototypes as Real Applications
 

In Lovable, prototypes can:

  • Connect to real databases (e.g., Supabase) for realistic, persistent data

  • Integrate directly with external APIs (e.g., OpenAI) to generate dynamic content

  • Respond to real user inputs, state changes, and async behaviors
     

As a result:

  • Prototypes behave like real software, not simulations

  • Design decisions can be validated against realistic data and edge cases

  • PMs and stakeholders evaluate actual flows, not approximations

This dramatically reduces the gap between "approved prototype" and "shippable experience."
 

Figma Make: Primarily UI-Level Fidelity

Figma Make excels at quickly generating UI and basic interactivity, but:

  • External database connections are limited or non-native

  • API integrations are not first-class or persistently managed

  • Dynamic behavior is typically mocked or simulated
     

This makes Figma Make best suited for:

  • Visual exploration

  • Static or lightly interactive demos

  • Early-stage concept validation
     

But it limits its usefulness for validating real product behavior.

5. Code Ownership, GitHub, and Production Flow

Another core difference is how prototypes live alongside production code.
 

Lovable: Prototypes as Branches of Reality

Lovable supports workflows where:

  • A real GitHub repository is connected

  • Prototype code can be edited both inside and outside Lovable

  • Changes remain synchronized

  • Prototypes can exist as branches that are reviewed, refined, and merged

This enables:

  • Clear ownership by Engineering

  • Standard code review and CI processes

  • A natural path from prototype → production
     

In this model, prototypes are not throwaway artifacts—they are early versions of the product itself.
 

Figma Make: Export-Based Code Handoff

With Figma Make:

  • Code typically lives inside Figma until exported

  • There is no native, bidirectional synchronization with GitHub

  • Versioning and review happen outside standard engineering workflows

As a result:

  • Code ownership is ambiguous

  • Iteration often forks between Make and the real codebase

  • Production readiness requires additional reconciliation work
     

This reinforces Figma Make’s role as a generator, not a production participant.

Decision Criteria
(How to Evaluate the Right Model)

If we optimize for the following outcomes, AI-first, code-native tools have a structural advantage over Figma Make:

  • Realistic validation → Prototypes must use real data, APIs, and behavior

  • Single source of truth → UI components and styles should not be mirrored

  • Low translation cost → Approved prototypes should not require rebuilds

  • Clear ownership → Code should live in GitHub with standard review and CI

  • Scalable consistency → Design systems should be enforced programmatically
     

If these outcomes are not priorities, a Figma-first workflow may remain sufficient. But if they are, the current model becomes a constraint rather than an enabler.

The Proposed Direction: AI-First, Code-Native Design

Prototypes and production should be built from the same components, tokens, and styles.

Instead of designing representations of the UI, we design with the UI itself.

​

What This Looks Like in Practice

1. Production UI System as the Source of Truth

In the proposed model, the design system lives in code first, not in a design file.
 

A shared, versioned UI system includes:

  • Design tokens (color, spacing, typography)

  • Core components (buttons, inputs, modals, tables)

  • Common patterns (forms, empty states, flows)
     

This system is consumed by:

  • Production applications

  • AI‑first prototyping tools (e.g., Lovable)
     

Why Keeping the Design System in Figma Is Limiting
 

When the design system is primarily authored and governed in Figma:

  • Components are representations of production components, not the components themselves

  • Drift is inevitable between visual spec and real behavior

  • New patterns must be re-implemented to be validated

  • AI tools are forced to interpret, not reuse
     

Even with MCP:

  • Figma remains a translation hub

  • The design system must be mirrored in code

  • Consistency relies on process, not enforcement
     

By contrast, AI-first tools like Lovable provide first-class design system support inside the code environment:

  • Design systems live as dedicated, reusable projects

  • Rules, components, and usage guidance are applied automatically during generation

  • Multiple design systems can be composed with deterministic priority when rules overlap
     

This shifts governance from documentation and review to programmatic enforcement, while still allowing flexibility where needed.

2. Lovable as the Primary Prototyping Environment

Lovable (or similar AI‑first tools) is not simply a faster way to mock UI—it changes what a prototype is.

Designers:

  • Compose screens using real, shared components

  • Operate within the same constraints as production

  • Style exclusively via tokens

  • Iterate on behavior, responsiveness, and hierarchy—not just appearance

Engineering:

  • Receives prototypes that already conform to production APIs

  • Reuses structure, not just ideas

  • Focuses effort on data, logic, and performance
    ​

Why This Is Different from Figma Make
 

With Figma Make:

  • Components used in Make are still mediated by Figma’s component model

  • Shared componentry is referential, not literal

  • Generated code must adapt to production libraries

With Lovable:

  • The prototype imports the same component package as production

  • There is no component translation step

  • “Handoff” becomes code review

3. Review and Collaboration Shift to Running Software

Instead of commenting on frames:

  • Teams review live previews

  • Iterate on behavior, not just appearance

  • Make decisions in context of real constraints
     

This preserves critique and collaboration while grounding it in reality.

Why the Figma MCP Approach Is a Complication, Not a Strategy

The proposal to rely on the Figma MCP server is a logical extension of a Figma‑first worldview—but it also highlights its limitations.

MCP Solves Access, Not Authority

Figma MCP allows AI tools and developers to read structured design data from Figma. This improves extraction fidelity, but it does not change the underlying model:

  • Figma remains the upstream source of truth

  • Code is still downstream and derivative

  • Design systems still need to be mirrored and reconciled
     

MCP optimizes translation; it does not eliminate it.

MCP Adds a New Integration Layer

Adopting MCP introduces:

  • Another system dependency

  • Another failure mode

  • Another surface area for drift and mismatch
     

In practice, teams must now reason about:

  • What lives in Figma vs code

  • What is authoritative when conflicts arise

  • How changes propagate across systems
     

This increases cognitive and operational overhead without removing the core handoff boundary.

MCP Is Defensive, Not Foundational

MCP exists to keep Figma relevant in a world where UI increasingly originates in code and AI tools. It is a bridging mechanism, not a new foundation.

By contrast, AI‑first tools remove the need for a bridge entirely by making code the shared substrate for design, prototyping, and production.

Why This Matters Long‑Term

Relying on MCP:

  • Locks us into a dual‑authority model (Figma + Git)

  • Makes design system governance harder, not easier

  • Optimizes an architecture that is already being bypassed
     

Using AI‑first, code‑native tools:

  • Establishes a single source of truth

  • Reduces system complexity

  • Aligns with where AI‑assisted product development is heading
     

For these reasons, MCP should be viewed as a transitional mitigation for Figma‑centric teams—not a viable long‑term or even medium‑term strategy.

Why This Is Better for Each Discipline

For Design

  • Less throwaway work

  • Clear constraints that scale creativity

  • Direct influence on what actually ships

  • Stronger ownership of patterns and systems

For Engineering

  • Reduced reimplementation cost

  • Fewer interpretation errors

  • Faster path from approval to merge

For Product

  • Shorter iteration cycles

  • Earlier validation with real UI

  • Less gap between "what we saw" and "what shipped"

What This Does Not Mean

  • Designers become engineers

  • Exploration and early ideation disappear

  • Visual thinking is devalued
     

Figma (or similar tools) may still be used for:

  • Early exploration

  • Conceptual work

  • Moodboarding or broad ideation
     

But it is no longer the handoff artifact or system of record.

Recommendation

We should intentionally move away from a Figma‑first workflow toward an AI‑first, code‑native model, with Lovable (or a similar tool) as the primary environment for both prototyping and early implementation.
 

Maintaining the design system and prototypes in code—rather than in design files—will:

  • Eliminate a persistent translation layer

  • Allow designers to work directly with production constraints

  • Enable higher‑fidelity validation using real data and APIs

  • Reduce rework and accelerate delivery
     

Figma should be repositioned as a supporting tool for exploration and ideation, not as the authoritative source of UI truth.

Version A: Neutral / Evaluative

We should evaluate a transition toward an AI-first, code-native design workflow, with Lovable (or a similar tool) used as the primary prototyping environment and a shared production UI system as the source of truth.
 

This evaluation should focus on:

  • Prototype-to-production reuse

  • Ability to validate real behavior (data, APIs, AI-driven interactions)

  • Design system consistency and enforcement

  • Designer and engineer experience
     

Figma would continue to play a role in early exploration and conceptual work, but would no longer be assumed to be the system of record for UI definition or handoff.

A time-boxed pilot would allow us to validate these assumptions before making a broader organizational change.

Version B: Strategic / Directional

We should intentionally move away from a Figma-first workflow toward an AI-first, code-native model, with Lovable (or a similar tool) as the primary environment for both prototyping and early implementation.

Maintaining the design system and prototypes in code—rather than in design files—will:

  • Eliminate a persistent translation layer

  • Allow designers to work directly with production constraints

  • Enable higher-fidelity validation using real data and APIs

  • Reduce rework and accelerate delivery

Figma should be repositioned as a supporting tool for exploration and ideation, not as the authoritative source of UI truth. This shift aligns our design practice with how modern products are increasingly built and iterated.

bottom of page