Grazy

Active Development

From live HTML to editable Figma layers

Bridge the gap between code and design. Capture live HTML and convert it into editable Figma layers, then export starter code for multiple platforms.

How It Works

Import HTML to Figma

Demo moved to YouTube to reduce on-site bandwidth usage.

Watch on YouTube

Capture live websites, selected HTML elements, and screenshots, then import the result into Figma as editable layers

Export to Code

Demo moved to YouTube to reduce on-site bandwidth usage.

Watch on YouTube

Export your Figma designs to starter code in multiple frameworks

Architecture overview

What looks like a simple bridge between HTML and Figma is actually a multi-stage translation system. Each step preserves a different kind of intent so the result can stay editable, exportable, and useful across design and development workflows.

Browser capture

The extension inspects live pages, captures selected elements or screenshots, and resolves layout, styles, images, SVGs, pseudo-elements, CSS variables, and framework utility classes.

Normalized payload

Captured UI is translated into a Figma-oriented JSON structure with sizing, spacing, typography, fills, gradients, shadows, and metadata preserved for import.

Figma reconstruction

The plugin rebuilds the interface as editable Figma nodes, including auto-layout frames, text, images, vectors, list structures, and fallback font handling.

Selection serializer

Designs can then move back out of Figma through a shared intermediate model that extracts layout, styling, typography, SVG identity, component metadata, and tokens.

Export adapters

Platform adapters generate code for web and native targets, with specialized logic for stacking, fonts, SVGs, tokens, component structure, and full-page sections.

Product layer

AI enhancement, queued exports, subscription gating, analytics, benchmark tracking, and build profiles sit around the core engine without exposing implementation details.

Engineering challenges

Most of the hard work sits in the translation details: deciding what a live UI element means, recreating it as design structure, then exporting it back into code without losing too much intent.

Capturing the messy web

Live interfaces rarely map cleanly to design layers. Grazy has to infer intent from computed styles, utility classes, inherited values, hidden elements, gradients, SVGs, images, and responsive layout behavior.

Rebuilding editable Figma layers

The import path is not a screenshot-to-canvas shortcut. It reconstructs editable nodes, auto-layout relationships, typography, fills, spacing, and image data so the output can still be designed with.

Maintaining export fidelity

The export pipeline has to preserve Figma semantics that code does not express directly, such as text auto-resize modes, stack order, nested component intent, SVG identity, and token naming.

Keeping the product shippable

The plugin grew into multiple build profiles, feature flags, tests, licensing states, and AI provider paths while still needing to fit inside the constraints of a Figma plugin runtime.

Translation engine

The most time-consuming part was building the code generation pipeline. It had to recognize component structure, preserve design semantics, and emit useful code for very different UI platforms.

Component detection and export required separating visual structure from reusable component intent.
The shared intermediate node model keeps platform adapters from each inventing their own interpretation of a Figma selection.
Web exports account for stacking, font embedding, SVG normalization, token names, responsive sections, and full-page segmentation.
Native-style adapters translate the same source model into different layout systems rather than only changing syntax.
AI enhancement is layered on top of deterministic code generation, so the baseline export remains usable even when AI is disabled.

Supported output families

HTML/CSSReactVueSvelteFlutterSwiftUIJetpack ComposeReact Native

Not every target has the same maturity level, but each one pushed the system to separate reusable design intent from framework-specific syntax.

Commercialization layer

Turning Grazy from a personal tool into a product meant adding the less visible parts of software: plans, licensing states, build variants, analytics, AI costs, release channels, and product limits.

A subscription and licensing layer now supports feature access for different product tiers.
Build profiles make it possible to prepare public, internal, lightweight, and client-specific versions from the same codebase.
AI enhancement, paid adapters, image export, and token extraction can be treated as product capabilities instead of one-off switches.
The implementation avoids exposing sensitive licensing details while still making the product architecture clearer.

Key Features

Export to code: HTML/CSS, React, Vue, Svelte, Flutter, SwiftUI, Jetpack Compose
Design system sync between code and Figma
AI workflow bridge: ChatGPT/v0 to Figma
QA & design review with overlay comparison
Browser capture for DOM elements, screenshots, and UI analysis
Living documentation from production UIs

Technology Stack

Browser ExtensionFigma PluginChromeFirefoxTypeScriptReactViteConvex

Clinical research and medical technology

The story of Grazy

Grazy was born out of a personal frustration I experienced while working as a designer. I lacked the proper tools that would allow me to quickly test and iterate designs based on live HTML elements. Additionally, there were so many times I needed to reproduce live design elements without access to older sources, because the code was in production, but legacy.

At first, it started off as a simple way to play around with Claude Code. I wanted to see how viable it would be to build a tool that imports live HTML into Figma. Armed with a decent understanding of HTML and of Figma autolayout constraints, I started to put something together.

It was the Christmas holidays, 2025, and I had some time to myself, so I started fleshing out the core functionality: a browser extension and the Figma plugin that would be the backbone of Grazy. It took me a couple of days to get it into a working state.

The next week I started to think: what if I could also export code? I was working on my portfolio in parallel and thought how useful it would be to design bits in Figma and export the code to refine them. So I began working and got it to a decent state in a couple of days.

I played around with it and built support for more UI frameworks to see how viable it could be. Then it clicked: this is the type of product that bridges the gap between designers and developers. It can save developers time and enable designers to try coding themselves. At the very least, it helps people better understand how HTML works.

When it started, the UI was entirely hacked together using Claude Code. Lately I have used Grazy itself to extract HTML from its own interface, import it into Figma, and use it in my marketing materials.

Discovered use cases

Here are some of my favorite uses-cases I have discovered for Grazy so far while working with it:

I also dogfooded it at work on a project where the live product was the only reliable source of truth. The import workflow helped me recreate UI where the original Figma sources no longer existed, and later helped turn a live product surface into the starting point for a design system.

Used the import functionality at work to recreate production UI when the original Figma sources were missing.
Used live product capture as the foundation for building a design system from an existing product.
Used Grazy code generation to build parts of the Grazy landing page and Plumy pages.
Export color and size tokens from the design system straight to production.
Using Grazy to extract live UI for marketing materials. This is by far my favorite use-case so far.
Using it to study how developers built interface elements I loved using.
Quick prototyping. I exported figma components straight to code to create a quick HTML prototype for a new feature at work.
By adding inline base64 image embedding, I also made it super viable as a tool for creating HTML newsletters and emails.
Used it to reverse-engineer some older newsletters at work.
Used it to extract some legacy HTML at work to refactor and bring up to date.

More demos

Competitive analysis - Capture demo

Demo moved to YouTube to reduce on-site bandwidth usage.

Watch on YouTube

Capturing and importing a pricing box from a live website. Audio and controls are enabled.

Email Newsletter - Capture demo

Demo moved to YouTube to reduce on-site bandwidth usage.

Watch on YouTube

Importing the design of a live email newsletter into Figma. Audio and controls are enabled.

Marketing materials I designed

Plugin Covers design

Design for the plugin covers

Plugin ui evolution

Stages of the plugin UI evolution from early prototype stages to current production

Launching Grazy

After polishing it up a bit, I decided to launch it so others might betatest it and get some feedback. That's when it hit me that I could really have a decent product on my hands, with perspective users in both the design and development communities.

So I spun up a landing page, added some content, and launched it. I have been chipping away daily ever since, incrementally making it better and adding new features that could make it better.

Lessons learned

1. AI can be incredibly helpful in cutting down time from idea to prototype and production. But you need to have a very solid understanding of architecture, design patterns and principles to be able to efficiently guide it and get the most out of it.

2. A single person can still launch a full product that solves real problems for real users. But it will take much more time than it would for a team. Yet if you can efficiently leverage tools like Github Copilot and Claude Code, you can shorten that time.

3. Building the product and adding features is only half the battle. Marketing, community building and user engagmenet is the really difficult part of helping you lift it off the ground.

4. Starting off a product free, will be a good way to make it difficult to later monetize it. Consider starting with a paid plan from the get go, even if it's a small amount. That also validates the need.

5. Don't rely on friends to help you with feedback, help or opinions. They will either hype you or simply not care. Seek out real users as fast as you can.

6. Building anything that does not have AI inside will effectively put a brake on your products growth during this time, and make it considerabley less attractive for users. Even if your design is solid and built for efficiency and privacy. It's a much much tougher sell.

Some fun facts

export targets tracked across web and native UI stacks

focused plugin test files covering adapters, import, SVG, licensing, queueing, and UI

build profiles for public, lite, internal, staging, and client-specific workflows

48k+

TypeScript and TSX lines in the Figma plugin codebase

9k+

source lines in the Firefox extension capture engine

releases since the first version in December 2025

So far, I have made 12 releases, with the first version being released on December 17, 2025.

The plugin underwent 3 major refactors for the codebase. Each one modularizing it more and more.

Biggest challenge faced

Building the translation engine that converts Figma structures into useful code. By far the most time-consuming part was improving component detection and export accuracy while testing against different samples, each with a different design and implementation approach.

Code

Although the code was executed using Claude code, and Github Copilot, architecture, translation and design patterns were all entirely done by me, same as the UI design and the initial concept, planning and feasibility study.

What's next for Grazy?

The plan is to continue working and refining it, while also working on:

1. Launch strategy - Currently working on this.

2. Monetization strategy - Completed. Preparing the legal paperwork and payment systems.

3. Licensing system - Built into the product layer and being refined as the launch strategy evolves.

4. User acquisition and community building - Ongoing. Need to make some videos showcasing how fast it works.

Some of the areas I am refining next include:

Deepening accessibility-aware code generation, especially semantic roles, states, labels, and platform-specific accessibility APIs.
Improving conversion fidelity across all adapters with stronger regression coverage for typography, stacking, SVGs, assets, and component structure.
Hardening newer framework exports, including Angular, Blazor, MudBlazor, Svelte, Vue, and React Native.
Expanding bundled exports into more portable project packages, especially external raster/SVG assets and multi-file component downloads.
Refining component detection so exports can move from visual code toward reusable starter components.

I loved working and building this suite of products, mostly because it gives me a break from the usual design work while giving me the freedom to experiment, learn and explore new technologies and workflows. Plus I can always do real-world testing of my own theories related to product.