HTML prototype vs Figma: what fits a developer-led team

For a developer-led team, especially one where a coding agent writes the UI, HTML prototypes usually fit better than Figma files: they are made of the same material as the product, render text and layout with a real browser engine, and can be written and read by the agent without a translation step. Figma stays stronger for free-form visual exploration, brand and illustration work, and design systems maintained by dedicated designers. Many teams end up using both, each for what it does well.

What changed with coding agents

The classic flow was: a designer draws in Figma, a developer translates the drawing into code. The translation was slow and lossy, but it was the only way.

A coding agent changes two things. It can write a screen in HTML and CSS in seconds, so a prototype no longer costs a day of work. And it reads CSS natively: a padding of 16px in a stylesheet means exactly one thing to it, while the same padding in a design file has to be found, interpreted and mapped to your components.

So the question is no longer “which tool draws better?” but “which artifact is the best input for the person or agent who will build the screen?”

Where HTML prototypes are stronger

• Real layout. Text wraps, flexbox distributes space, a long name pushes the button to a second line. The prototype shows the problems the product will have, because it uses the same engine: flexbox behaves the same in a prototype and in your app.
• No translation. The agent that writes the prototype can reuse its structure and values when it codes the real screen.
• Real content. It is easy to paste real labels and 40 rows of realistic data, which is where designs break.
• Text-based history. Each version is a file you can diff, store and review like code.
• Every state is cheap. Empty, loading, error, modal open: each one is another small HTML page.

Where Figma is stronger

• Free exploration. Dragging, resizing and trying ten things in a minute is faster by hand on a canvas than through prompts.
• Visual craft. Illustration, brand identity, icon work and marketing visuals are design work, not layout work.
• Design systems with designers. Components, variants, variables and styles maintained by a design team, shared across products.
• Collaboration around the drawing. Comments, multiplayer editing and a shared file that non-developers already know how to use.

If your team has designers who think in Figma, forcing everything into HTML takes a tool away from them without a clear gain.

A side-by-side comparison

Criterion	HTML prototype	Figma file
Who writes it fastest	A coding agent, from a prompt	A designer, by hand
Layout fidelity	Real browser layout and text wrapping	Close, but its own layout model
Path to code	Same material, little translation	Needs a translation to CSS and components
Free visual exploration	Slower, through prompts	Fast, by direct manipulation
Review by non-developers	Needs a viewer or a canvas	Familiar to most teams
History and diffs	Text versions, easy to compare	Version history inside the tool
Design system upkeep	Tokens as CSS variables	Components and variables in libraries

The rows that matter most depend on who builds your UI. If the answer is “a developer with an agent”, the first three rows tend to decide.

The pitfalls of HTML prototypes

HTML prototypes have their own failure modes. Most come from treating them like the app.

1. Scope creep. A prototype grows scripts, state and API calls, and becomes a second app nobody maintains. Keep it to one state per page, with no logic.
2. Network dependencies. Remote fonts and images break, change, or leak requests. Inline what you need, use data: images or plain blocks.
3. Missing states. Only the happy path gets drawn. List the states before prototyping.
4. Placeholder text. “Lorem ipsum” hides the long labels and big numbers that break a layout.

A minimal self-contained frame looks like this:

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<style>
  :root { --accent: #0011ff; --radius: 12px; --space: 16px; }
  body { margin: 0; font: 16px/1.4 system-ui, sans-serif; }
  .card { display: flex; flex-direction: column; gap: var(--space);
          padding: var(--space); border-radius: var(--radius); }
  .primary { background: var(--accent); color: #fff; padding: 12px;
             border: 0; border-radius: var(--radius); }
</style>
</head>
<body>
  <main class="card">
    <h1>Invoices</h1>
    <p>No invoice yet. Create one to get paid.</p>
    <button class="primary">New invoice</button>
  </main>
</body>
</html>

No script, no external resource, tokens as CSS variables, flexbox for layout. An agent can write dozens of these, and each one maps directly to the code it will write later. The mapping from design tools goes the other way in Figma auto layout to CSS flexbox.

How to decide for your project

Answer these questions honestly:

• Who will build the screens: a developer with a coding agent, or a separate front-end team from specs?
• Do you have a designer who works in Figma daily?
• Is the work mostly layout and states of product screens, or brand and visual identity?
• Do non-developers need to review and comment on the design?
• Does a design system already live in Figma?

Mostly “developer with an agent” and “product screens”: start with HTML prototypes. Mostly “designer” and “brand”: keep Figma as the source, and hand the agent tokens and specs. Mixed answers: use Figma for the visual language and HTML prototypes for screens and states. The difference between fidelity levels is covered in wireframe, mockup or prototype.

One source of truth per concern

Using both tools only works if each question has one answer in one place:

• Brand, illustration, icons: the Figma file.
• Colors, spacing, radii, type scale: tokens written as CSS variables in the repository, copied from Figma when a designer changes them.
• Screens and their states: the HTML prototypes.
• Behavior and data: the code.

When the same value lives in two places, sooner or later they disagree, and the agent follows whichever one it read last.

A mixed workflow with agentappbuilder

agentappbuilder takes the HTML side of that split. Claude Code writes each screen state as a self-contained HTML frame on a canvas, the states are linked by the actions between them, and you review, compare versions and choose what gets built. Frames render in a sandboxed iframe with a content security policy that blocks every network request, as described in how prototypes are rendered.

For small visual changes, you do not need to go back to a design tool. You can edit a frame on the canvas with a Design panel that uses Figma’s names: fill, stroke, corner radius, padding, auto layout for flex containers, and text properties. Your edits become a new version that the agent reads and implements. Layers and adding, removing or moving elements are coming next.

The short answer

If a coding agent builds your UI, prototype in the material it ships: HTML and CSS, one state per page, no logic. Keep Figma where drawing by hand and designer collaboration matter. The best setup is the one where the prototype your team agreed on is also the easiest thing for the builder to read.