I launched Esprit Code – a tool that converts Figma designs to HTML/CSS instantly
Hey IH! 👋 I'm Keita, an indie developer based in Japan.
After spending too many hours manually converting Figma designs
to HTML/CSS, I built Esprit Code to eliminate that repetitive work.
🚀 What it does:
- Auto Layout → CSS Flexbox
- Grid Layout → CSS Grid
- Masks, gradients & blend modes
- Multi-frame export in one click
The conversion engine is built with Node.js and uses the Figma
REST API directly. Real-time progress updates via SSE keep
users informed during conversion.
📊 Current status:
- Launched 4 days ago
- First real user signed up within days of launch
- Free plan available (no credit card required)
💰 Pricing:
- Free: 5 conversions/month
- Starter: $10/month (30 conversions)
- Pro: $25/month (100 conversions)
- Power: $100/month (500 conversions)
Would love feedback from anyone who's dealt with the
design-to-code handoff pain point — especially what
Figma features matter most to you.
Trending on Indie Hackers
This is so cool. As a designer I have tried other tools that claimed to give similar results but a big problem was getting code that was more of a headache to clean up than writing from scratch so I'm really happy to see the batch exports, and creation of file strutcure would definitely check it out
Hi @Beth15475, thanks for this thoughtful comment, and sorry for the very delayed reply — got caught up with the launch and then a health setback.
You're touching on the exact pain point that drove me to build this. Most Figma-to-code tools generate output that's either so over-structured or so messy that cleanup takes longer than hand-coding from scratch. The whole value disappears at that point.
I focused on making the output something a developer would actually want to inherit:
Batch exports come from the same principle — real projects have 5-20 frames, not just one. Doing them one at a time wastes time.
Free plan has 5 conversions/month if you want to try it on a real design — would love to hear if the output meets your "less headache than hand-coding" bar.
Hey Keita! Really impressive getting your first real user
within days of launch, that early validation is everything.
The design-to-code handoff problem is huge. Interesting that
you went Node.js with the Figma REST API directly rather than
using a plugin approach, was that a conscious decision for
performance reasons?
I'm also at the very early stage with my tool RankFlow —
a programmatic SEO publisher for WordPress. Just got my
first external user testing it today actually. The "first
real user finds all the bugs" experience is very real! 😄
Would be curious how you're planning to grow beyond the
initial launch buzz, that seems to be the hardest part.
Hi @Smartpubtools, thanks for the comment, and sorry for the delayed reply.
The Node.js + REST API path was deliberate. Plugin-based approaches put the conversion logic inside Figma (which constrains processing power and UI), while a separate backend lets me run heavier transforms — especially for things like geometry parsing, mask processing, and batch exports.
The tradeoff is the API rate limit (the View-only seat issue is real — 6 calls/month is brutal for testing). I've optimized by minimizing redundant API calls and using semaphore-based parallel processing where it helps.
On growth beyond launch buzz: that's the hard part you're right about. The current plan is:
The launch spike fades fast, but accumulated SEO traffic compounds. That's the bet I'm making for the next 3-6 months.
RankFlow sounds interesting — first external user is a meaningful milestone. How are you handling the WordPress publishing API? Custom integration or a plugin approach?
Figma-to-code tools live or die on how well they handle edge cases like nested auto-layout and custom components. Curious what your output looks like for something like a complex card grid with responsive breakpoints - that's where most converters I've seen fall apart. What's the biggest technical challenge you hit building it?
Hi @ShellSageAI, thanks for asking — these edge cases are exactly where the product gets tested.
For nested Auto Layout: the engine handles arbitrary depth recursively. Each level generates its own Flexbox context with the correct flex-direction, justify-content, align-items, and gap values. Sizing modes (FIXED/HUG/FILL) translate to width/height + fit-content + flex-grow combinations.
For a responsive card grid: the honest answer is that EspritCode generates CSS Grid (or Flexbox) for the visible layout, but breakpoints are not auto-generated — the developer adds responsive rules at the polish stage. This is part of the "starting point, not finished product" philosophy.
The biggest technical challenge: probably gradient strokes combined with border-radius. CSS uses
border-imagefor gradient borders, butborder-imageoverridesborder-radiusat the spec level. There's no clean CSS fix — only approximation strategies. Tools that promise "perfect" reproduction in these cases are just lying or ignoring the issue.Custom components are another area where things get hard — Figma component variants don't always translate cleanly to CSS class variants. Still iterating on that.
What kind of conversion challenges are you working with most often?
Hi Keita!
Love your tool. The issue is, I have seen some tools solving the same problem you do. But, it's not mean you've got no choice, but you have to diferentiate your self from the others. That can be anything including sheer quality - if your tool's output is better than others, then you will gain more users. And the other way is just intelligent marketing, that is finding ICPs before your competitors do.
i have seen some posts in Reddit, building the same thing, will share you next time when i see.
Great idea! Especially being a Web Dev for 20+ years. This definitely comes in handy!
This would save so much time for people who hate the handoff between design and dev.
That gap is where a lot of projects slow down or get messy.
How clean is the output when it comes to real production use?
Congrats on the launch — and on getting a real user within days. That first signup hits different when you've been building in isolation.
We launched our own tool this week too, so the early-days feeling is fresh. The thing nobody tells you about the first 48 hours: you stop thinking about features and start thinking about what real users actually do with your product. The gap between what you built for and how people actually use it shows up fast.
The Figma-to-code handoff is a pain point we've watched designers struggle with firsthand. The technical conversion part (Auto Layout to Flexbox, Grid to CSS Grid) is the expected value. But the real test is probably edge cases — what happens when a designer doesn't use Auto Layout properly, or when the Figma file is messy? That's where most design-to-code tools break down. Clean Figma files convert beautifully. Real-world Figma files are chaos.
Curious about two things:
First — how are you handling responsive output? A Figma frame is a fixed canvas, but the HTML needs to work across breakpoints. That translation layer seems like where the most value (and the most complexity) lives.
Second — at your pricing tiers ($10 to $100), what's the deciding factor between plans? Is it volume of conversions, or do higher tiers unlock specific features like multi-frame export? Early pricing is one of the hardest things to get right, and the signal from which plan people pick tells you a lot about who your real user is.
Hi @FoundryTwo, thanks for this detailed comment — sorry for the late reply. The two questions you raised are the right ones.
On responsive output: this is the honest weak point. EspritCode generates the layout for the Figma frame you point it at — which is a fixed canvas. The output works at that breakpoint, and the developer adds media queries to handle others. We don't currently auto-generate multi-breakpoint output, because Figma files rarely expose enough information about how each frame should adapt across breakpoints (designers often only design one or two breakpoints by hand).
I've thought about supporting multi-frame mode where the user selects a desktop frame + tablet frame + mobile frame, and EspritCode generates the unified responsive CSS. That's on the roadmap but not shipped yet. For now, the responsive layer is the developer's polish work — which is also part of "what needs human judgment."
On pricing tiers: the difference between Free / Starter / Pro / Power is purely conversion volume right now (5 / 30 / 100 / 500 per month). No feature gating. The reasoning was simplicity at launch — every user gets the full conversion engine, and they pay for how often they use it.
That said, your point about pricing signal is sharp. The plan distribution will tell me a lot:
Too early to read the data — beta launched only weeks ago. But the question is on my mind.
What did you launch this week? Curious to see how your first 48 hours played out.
How can you measure differences between your tool and pencildev ? I would love to find a solid design to code app actually
The design-to-code gap is real — I've been deep in this problem too, working on component portability across design tools.
One thing I've found: the hardest part isn't layout (flexbox mapping is well understood now). It's the stuff Figma doesn't expose cleanly — component variants, interaction states, responsive rules. If you're using the REST API you can get some of that, but the rate limits are brutal (View-only seats get 6/month). Hit that ceiling pretty fast.
Curious: does Esprit Code handle components with variants? Like a Button with hover/pressed/disabled states — does it generate separate CSS classes for each, or just convert the default state? I've been exploring that gap — component libraries often lose the interaction context entirely.
This is really useful. I’ve done Figma to HTML manually before and it takes a lot of time for small changes.
One thing I’ve seen is people care a lot about how clean the output code is, not just the conversion. If the code is easy to edit later, that becomes a big advantage.
Also maybe showing a real before → after example could help people trust it faster.
Tools like this are great when people can instantly see the before-and-after. For example: a Figma frame on one side and the generated HTML/CSS on the other in a quick walkthrough. That kind of visual demo can be very powerful for landing pages and social posts. I help startups create short product launch and demo videos that highlight workflows like this, so if you ever want to promote Esprit Code more visually I’d be glad to help.
The design to code handoff is honestly one of the most underrated pain points in app development.
We work with designers and developers both and this gap causes lot of back and forth. Designer thinks it looks exactly like Figma. Developer says it was never possible to build exactly like that. Client is confused why final product looks different from the design.
The Auto Layout to Flexbox conversion is the part I am most curious about honestly. That is where most tools struggle. Figma auto layout has so many edge cases that just dont translate cleanly to CSS.
How are you handling responsive breakpoints? That is usually where Figma to code tools start showing cracks in our experience 😄
I remember the days I was taught this exact process of manually creating pages from Figma. It was 4-5 years ago. That's great, you created this automation. Great product!