This April, we've rolled out major features and improvements that we're confident will elevate your FireJet experience:

🎁 Pricing​

🚀 Pro Plus Plan​

To cater to teams looking to accelerate their workflow on a larger scale.

• 298USD / user / organization
• New pricing tier with advanced features dedicated to advanced web development needs.
  • Includes:
    • Everything in Pro
    • Multi Breakpoint Input
    • Auto Detect Figma Components
    • Advanced Semantic Element Tagging
    • Figma Design System to Component Library
  • Currently closed access! Book a call here for access!

💼 Enterprise Custom Solutions​

Customized solutions to scale your design to code workflow with enterprise support.

• Includes:
  • Everything in Pro
  • Android & IOS Support
  • 3rd Party Integration
  • On-Prem Support
  • Enterprise Support
  • Additional Feature Requests Book a demo here for access!

🔥 New Features​

Improved Code Quality

Improved code generation algorithm with better object detection and responsiveness prediction using our own AI model. Code quality should be generally better now based on the feedback.

🚀 Pro Plus Features​

Only Pro Plus access for now

1. Multi Breakpoint Input​

Generate responsive outputs by selecting frames of different breakpoints for the same design. Currently works for 2 screen widths (i.e. mobile and desktop widths). Hold SHIFT and select the mobile and desktop designs in Figma before generating code.

2. Auto-Detect Components​

Detects Figma components, their variants, and variables and generates them as code components. The properties in the Figma component can now be reflected in the generated code as React component proprerties.

3. Figma Design System to Component Library​

npm install and import Figma components directly into your codebase. Any updates to Figma components also updates the component library. Select all your Figma components and click "Publish", all components will now be uploaded to a git repo, where users can import them into their code repository as an npm package of components, complete with component props carried forward from Figma.

4. Advanced Semantic Tagging​

Advanced detection and generation of semantic elements such as dropdowns and inputs using HeadlessUI or Radix components. Detected semantic elements can be replaced with fully functional semantic components from popular component libraries. Future support for components beyond just semantic (e.g menubar, radiogroup) will be added

Introduction​

One thing I keep doing is keep hyping up how much better the conversion is compared to other plugins, or even as compared to using ChatGPT by itself, but as technical people we usually want a proper explanation instead of some bullshit promise.

In this article I will be sharing some of technical aspects of FireJet, and how it makes FireJet stand out from the rest

What Chess Engines and FireJet have in common​

The harsh reality when it comes to figma designs, is that more often than not, the designs are not properly nested the same way you would nest them in code.

Take the below image for example:

To us as coders its quite straightforward - They should be in a flex column aligned left, and the input should have a placeholder text of 'Enter username'

Now look at the nesting provided from the figma design:

There are a few things to take note of:

1. Everything is absolute positioned
2. Nothing is nested
3. There are two nodes making up the input - the text node and the box node

So to improve the code, we need to:

1. Find the best groups
2. Combine the text and the input into a single element
3. Find the best flexbox position for each node

For the above design it's relatively trivial, but when it comes to more complicated designs it suddenly gets a bit trickier

Once again, to our human eye it's pretty easy to tell that the calendar should be in a grid, but in terms of raw possible groupings, there are tens of thousands of groups.

Stockfish the chess engine​

Similar to how there are many, many possible groups, in chess there are also many, many possible positions. It's computationally infeasible to compare all of them to find the best group, so how do chess engines do it?

How Stockfish NNUE does it is pretty interesting - first it calculates all the possible moves up to a certain depth (e.g. 10)

Then, from each leaf node, it uses a neural network to decide how optimal each leaf node is, and it goes in the direction which has the most optimal leaf nodes.

Similarly, firejet does the same - it finds groups up to a certain depth, decides which groups are the best using our own super-top-secret method of scoring leaf nodes, then pruning and moving forward until the best possible groups are found, regardless of how the original design was structured.

Technical challenges we encountered​

Implementing this system was kind of challenging, and took quite a fair bit of grinding

But it wasn't the first time we made such a system - we had implemented a similar system for engine 1 of FireJet, but that had several issues that warranted a full rewrite of the system

Identical positions​

For chess engines, when building the tree of possible moves, a piece can move back to a square that it has already visited. As you can imagine calculating the score for move would be a waste of computing resources.

Similarly, such scenarios can arise from computing the best possible groups in FireJet

As you can see from the above image, both of the original starting points eventually lead to the same group. Since the number of nodes that we can check to obtain the best position from are limited, by pruning the duplicates we are able to explore alot more possible moves.

Dynamic Programming​

For chess you are able to evaluate how strong a position is based solely on the current position of pieces on the board. However, such a calculation for our grouping algorithm would mean expensive calculations for every possible leaf node, which was taking up alot of our computing resources.

The solution we came up with was to make the score based on the previous group's score - by just incrementing or decrementing the previous score we were able to save alot of computation time and explore more leaf nodes to get the best groups.

Running locally vs on Cloud​

When we first implemented the system, we actually ran the optimisation algorithm locally on the users computer - This was because alot of the operations that needed to be performed were easier to perform with direct access to figma's API.

The problem with that is, not everyone has 24GB of RAM on their laptop like me, so we were getting constant report of out of memory errors from users around the world.

We implemented a serialization algorithm to quickly rebuild the figma structure directly in our backend, which resolved the issue.

How FireJet compares to just GPT4 vision​

The way GPT 4 vision works is by converting images to fit 2048x2048 squares, then further reducing the image size if the shorted side is more than 768px, then converting each box to 512x512 squares.

Each 512 by 512 square is converted to 170 tokens on high detail mode

What this means is that for every 512x512 square, chatgpt gets to write a 100 word summary (assuming every word is worth 2 tokens) describing the square, which as you might imagine would lose some details.

However, firejet produces an entirely deterministic output, keeping every single important detail required to render the image.

So with firejet you get consistent results that are as pixel perfect as possible.

Nevertheless, GPT is extremely capable in improving code quality and readability, which is why it also exists as a post-processing step when using FireJet. (Which you can use from directly within the plugin!)

How FireJet compares to other figma to code tools​

There are a two categories of figma to code tools which we can compare to: The figma-accurate tools and the AI powered tools

figma-accurate Figma to Code tools​

There are quite a few tools that give you designs exactly how you would see them in Figma - The problem is then you must use Figma's auto layout for everything, which is quite difficult to do.

For example, you would have to get your designer to change their workflow to strictly use auto layout for everything - something that gets ALOT of pushback in our experience.

Even if your designers mostly use autolayout, you may be surprised that sometimes these competitor tools will still give you absolute positioned nodes - because the truth is its very easy to accidentally not use autolayout, or order your elements wrongly - even though the design will still look great, you will find that everything is no longer aligned.

If you're willing to ask your designer to redesign your whole layout from scratch, the other figma to code tools without the autofixer may work for you. However, for most real world figma designs, FireJet should perform better.

AI Figma to Code tools​

For AI powered tools, they run into the same limitations as GPT + vision (For now) - They may lose some visual fidelity, and may not provide the most accurate results. What you get today may not be what you get tomorrow, and when we tried some of such tools ourselves several of them just converted entire portions of our design into images, which were unusable because they were supposed to be interactive.

Introduction​

One of the biggest challenges in the Figma-to-code space is maintaining high code quality. So how can we address this? We are thrilled to introduce GPT-4 Vision AI and its impact on our code generation process.

What is GPT-4 Vision?​

GPT-4 Vision is the next leap in OpenAI's API capabilities that allows the understanding and processing of images.

What does that mean for us?​

The ability to understand images allows for a direct comparison between the generated code and the initial design. This comparison lays the foundation for further refinements, ensuring the final code not only matches the design visually but also functions as intended. Below are the enhancements we've implemented to bolster our code output.

Semantic Element Detection​

With GPT-4 Vision, we can now accurately predict the functionality of design elements such as buttons and input fields. This means that converting your Figma designs into code will not only yield a semantically sound structure but also make it generally more SEO-friendly

Originally generated code​

Semantic predicton with GPT Vision​

Removing unecessary divs and CSS​

Designs in Figma may not always be optimized for code generation, often resulting in unnecessarily nested frames and repeated CSS that do not translate well into code structure. GPT-4 Vision tackles this issue by identifying and eliminating all unecessary divs and CSS found within the initial generation. This massively simplifies the code to enhance usability and improve the overall production quality.

Originally generated code​

Reduced nesting and simplified styles with GPT Vision​

File renaming (Coming soon)​

Designers under time constraints may leave Figma frames improperly named, leading to a sea of nondescript names like "Frame 237" in the generated codebase. This lack of clarity makes it difficult to navigate the generated code. GPT-4 Vision will soon be able to intelligently rename files based on their appearance. For instance, a button labeled "Get Started" in the design could be aptly named "GetStartedButton," simplifying codebase navigation.

Start your journey​

With the integration of AI into FireJet, code quality will only get better from now. Feel free to experience the refined code quality yourself! Our commitment extends beyond mere design conversion; we aim for your code to be as efficient and maintainable as possible.

Get started here!

Why we startup differently

There's a massive overload of product-related frameworks out there these days: SCRUM, SWOT Analysis, AARRR, JTBD, BMC—the acronyms are endless. I do applaud the effectiveness of these frameworks, and I have done my fair share of reading, but the thing is…

It just doesn't work for us. Let me explain why:

Reasons Why Traditional Frameworks Don't Work for Us​

1. We Can Code Faster

   My CTO is a god-tier coder. It takes 1 week for us to build an MVP and another for us to validate the idea. Whereas, talking to 100 people would take us months. Build fast, fail faster!

2. We Are a Small Team

   We have 2 co-founders. Being in a small team means we can iterate faster than anyone else. We can make decisions faster.

3. We Can't Sell for Nuts

   We are engineers at heart and love to code. We can't sell for nuts, but we can build whatever you want. Recognizing our weaknesses and leveraging on our strengths is crucial.

What Works for Us​

1. Build Product
2. Talk to Users
3. Repeat

We're not saying frameworks are bad. We tried them, but they're just not for us. Our team is small, we make things quickly, and although we're not good at selling, we excel at coding.

Being a startup means finding what works for you, even if it's not the usual way.

Code fast, iterate faster, and let the product speak for itself.​

YC Interviews

We've applied to YC four times, and we've gotten to the interview round twice.

I'm not sure about my cofounder Stephen, but I get really excited about these interviews because you get to meet with and chat with some really big names in the startup space (albeit only for 10 minutes)

Some of the people who interviewed us were:

Gustaf Alstromer - Prev. Product Lead at Airbnb
Brad Flora - Cofounder, Perfect Audience
Harj Taggar - Cofounder, Triplebyte
Richard Aberman - Cofounder, WePay
Stephanie Simon - Head of Admissions, YC

Its was like getting to meet your favourite celebrities in person. The same people from the YC videos talking about million dollar deals and all the startups they've advised, coming online to a zoom call with you - Walking through your idea, giving you advice (and sometimes investments) - naturally it's like a dream come true.

Our YC Application Statistics​

Our Interview Experience​

The YC interviews were really exciting, but unfortunately they were at 3am in our timezone (Singapore) so usually we would have to wake up in the middle of the night to prepare for the interview.

In the Zoom waiting room​

For our first interview, it started about 20 mins late.
For our second interview it started exactly on time.

Entering the Zoom call​

Each YC interview had three YC partners inside.
Each interview was also led by a single partner, for our first interview it was led by Gustaf and the second interview was led by Harj.

Intial Interview Questions​

I can guarantee the following questions, or something similar, will be asked:

1. What are you working on?
2. How has your progress been so far?

While you would have already provided these details in the YC application, they want to hear it again from you - in order to gauge your ability to communicate your ideas.

Followup Interview Questions​

After they asked the initial questions, they asked some followup questions regarding our competition, and what made our product unique.

Style of Interview​

During our first interview, if I started talking for too long I would be stopped so that they could move on to the next question. (We were not interrupted during the second interview)

Be prepared to be interrupted, and don't be offended. Ten minutes is a really short time for an interview which necessiates the interruptions.

Followup​

Usually we received our response regarding whether we were successful or not 5 or 6 hours after the interview.

W22 - EzBackend (Top 10%)​

When Stephen and I graduated from university, the first thing we started work on was EzBackend, which was inspired by our frustrations with the repetitive tasks involved in setting up a backend, like having to manually create the same create, read, update, delete API endpoints for everything, and having to manually write API documentation, etc

Why we were in the top 10% of appplicants​

YC has two main tenets - Talking to users and building product. In our application, we demonstrated our ability to build fast (Built MVP in 2 weeks) and our willingness to talk to users (6 interviews in 1 week)

Why we did not get the interview​

Personally I still think that this is quite a good idea, it's just really strange for two fresh graduates to be the ones to execute the idea. Great idea, but the team didn't have the credentials to back it up.

S22 - FireJet (Interviewed with YC)​

While working on EzBackend we had secured a deal with another startup to build their MVP for 8.7k USD. We did most of the design discussions via Figma, and naturally the question of whether we could convert those designs to code popped up in our minds.

We didn't want to become a services company, and we were having trouble monetizing EzBackend.

Since there were existing Figma to Code tools in the market, we decided that if any of them were usable, we would pay for them and not pursue this idea.

The crazy thing was, NONE of the competitors had working products, so we immediately jumped into the space and hacked out a quick MVP.

Why we got the interview​

One of the questions in the YC application was to share a demo url, and in a major flex on our part we shared the reddit link of the demo with 267 upvotes, which probably caught their attention.

YC's motto is build something people want - and I think that was very clear from the upvotes on the reddit post.

We also demonstrated the same speed of execution (Which I believe is really important), having built the MVP in 3 weeks, and gained 167 downloads in the first week,

Why we got rejected after the interview​

To summarise Stephnaie's points on why YC rejected us:

1. Several unsuccessful competitors
2. High churn rate

And their advice for us

1. Keep talking to users

We spent quite a few days moping after being rejected, but in hindsight, I think that it doesn't really matter - What's more important is to keep the same speed of execution and talking to users in order to build something people want.

W23 - FireJet (Not top 10%)​

Why we did not get the interview (Not even top 10%)​

We had made very little progress in 7 months, and we hadn't solved the differentiation nor the churn problem from the previous YC interview.

It was okay that we had not received the traction that we were looking for, but the main problem was the major drop in speed of execution, which I boils down to 3 things:

1. We did not have enough / did not have effective user interviews
2. Our speed of execution dropped significantly
3. We did not solve our churn issue

S23 - FireJet (Interviewed with YC)​

Why we got the interview​

I think traction is king - we added a feature (componentization) which significantly improved the quality of outputted code from FireJet. As a result, our revenue jumped significantly and we were able to prove our ability to monetise.

The interview​

One of the things that stumped us during this interview went like this:

YC Partners: Who are your users?

FireJet: Development houses in India, Vietnam, and the US

YC Partners: Who are your paying customers?

FireJet: Usually larger companies with more purchasing power

YC Partners: And what do larger companies want?

And the reason this stumped us was because we knew what our users wanted:

1. Readable Code
2. Pixel Perfection
3. Responsive Designs

But we didn't know the specific answer for what the higher paying users wanted - we had not actively seperated our feedback by paying customers versus non-paying customers.

Why we got rejected after the interview​

To summarise Richard's points on why they rejected us:

1. Competitive space
2. No clear differentiation

And his advice:

1. Focus on the high revenue paying users and retaining them.

What we've done since then​

Continuing our Current Idea - FireJet​

Even internally we've had issues with retention - when building a Software-as-a-Service (SaaS) company the main driver of revenue growth is usually customers continuing subscribe to your service.

In our opinion, what customers really want is high quality code.

But what the Figma to Code companies want is high retention, and the thing about outputting high quality code is that the moment you get it, you no longer need the tool, hence leading to an unsubscription.

We are still focused on building what people want, which is a really accurate figma to code tool, whereas our competitors are more focused on adding additional features like adding functionalities and stuff straight from figma to increase retention.

However, we are continuing to struggle with retention, so we've been looking at other ideas as well.

Trying new Ideas - ContenX​

Background​

I've always wanted to share more publicly about our startup's journey (In order to drive more traffic to FireJet of course 🔥) but I've always been very lazy to do it because catering the content for reddit, linkedin and twitter was time consuming.

This is because what works on linkedin doesn't work on reddit, and eventually you'll end up on r/linkedinlunatics, whereas what works on reddit is not engaging enough for linkedin.

I've tried searching for ways to convert between the different formats, but I couldn't find a tool that could do that.

So, shameless self plug, we made contenx.io in order to turn one piece of content into ten (Get it? Content 10x?)

Also I'm a really avid squash player (see my rank here), but usually the optimal time to make the social media posts is when I'm at squash, which is why we've added the ability to schedule posts from contenx as well.

Why I think ContenX will help us get into YC​

1. Fast Execution - We built and launched the MVP in 1 week
2. Early Customer Demand - We had 198 users in the first week, and with no advertising, we are still getting 25 users a day
3. We're talking to users - After building, we've reached out to users to get feedback and implemented their feedback within the week
4. Early signs of retention - Our retention statistics are much higher than FireJet, because people need to create new content all the time

Conclusions​

I strongly believe getting into YC should not be the goal - the goal is to build a good startup, and whatever YC teaches lets you achieve that.

Here's what got us to the YC interviews

• Fast Execution
• Talking to users

And here's why we didn't get into YC

• Lack of differentiation
• High churn

So it really doesn't matter how much you fluff up your application - your time is much better spent building your startup, and if your startup is good, you'll probably be accepted into YC.

One last story...​

One night I was staying over at Stephen's house to prepare for the interview. We had discussed our metrics and aligned our goals and ideas for FireJet, and we were feeling well prepared, so we went to sleep.

So we woke up, and it was showtime, so while I went to make coffee for the both of us, Stephen went to setup the zoom call.

Halfway while the water was boiling, I heard howling laughter coming from Stephen's room, so naturally I went over to ask him what was wrong.

He then showed me the calendar invite for the YC interview - apparently we were one day early, and woke up for nothing.

Long story short, Stephen is very bad at dates (Although I should have checked the dates as well)

Posting on reddit

Over the years, we've hacked together several products, and to check if anyone cares, we released them for free on reddit.

In this post we'll be sharing the statistics from each released product, and a summary of all our learnings.

Interesting Statistics​

1. 51.3% of our traffic was mobile *
2. Performance for different media types:

• Video (41 upvotes/sub)
• Website (45 upvotes/sub)**
• Youtube Link (3 upvotes/sub)
• Text (1 upvote/sub)

* 51.3% is for all website visits, I suspect reddit users are even more likely to be mobile users
** While the website got more upvotes per sub, we only posted a website link once so results may not be accurate

Statistics​

Post content and descriptions​

Best practices​

Use videos when getting feedback​

Comparing the posts that included videos versus those that didnt, those with videos on average had more than 30 upvotes/sub each, whereas those without videos got less than 5 upvotes/sub

What we consider when making our videos:

1. Text large enough to view on mobile
2. Short ( < 2min )
3. Include subtitles

Make sure your post is mobile friendly​

Our ContenX analytics show the following results

Both your introduction video and product should work on mobile - otherwise, you're losing half your audience

Remove logins and only get feedback for free products​

Self advertising is a huge turnoff for redditors.

I believe that reddit as a platform should be used to test if people want your product, and not selling. If you want to get people's feedback, make it as accessible to everyone as possible.

Don't link to youtube, post direct video on reddit​

The time it takes for youtube to load, (especially on mobile), followed by any ads that your users may watch will cause significant churn in your funnel.

Don't use promotional language​

Imagine reading the following post on reddit:

Introducing ezpets: Bridging Pet Owners with Wholesale Accessory and Food Sellers!

Hey Redditors! 🐾 We're thrilled to unveil ezpets - a two-sided marketplace designed to connect passionate pet owners directly with top-notch wholesale sellers for pet accessories and food. Why pay retail when you can access quality products at wholesale prices? Dive in, discover, and let your furry friends enjoy the best without breaking the bank. Your feedback is invaluable to us. Check us out!

1. Shorten 'Introducing ezpets' to 'ezpets'
2. Remove the emoji
3. Remove words like 'thrilled' and 'unveil'
4. Remove exclamation marks
5. Rephrase the 'Why pay retail when you can...' with a more factual statement instead of trying to be attention grabbing

The easiest way to understand the mindset of redditors is to use reddit yourself - and try to imagine how you would feel coming across your own post in the wild

Make something people want​

Quite frankly, if you've made something people want, it will always be upvoted regardless of how poor your phrasing is.

For example figma to code tools - everyone loves them and there's been at least 5 seperate launches of figma to code tools on product hunt and all 5 of them were product of the day

Celebrate personal wins as part of the community​

If you've put in alot of effort into your product, don't be afraid to show it.

For example, if you've spent 4 months building something, you can make a post like

"I've spent the past 4 months building XXX"

If you're building something technical, don't be afraid to share the technical infrastructure, and if you've had some traction, share that too - posts with more details and sharing of knowledge tend to be upvoted more

Our biggest mistakes​

Posting the wrong link​

Our ContenX post did particularly poorly because... we posted the wrong link like the fools we are. (www.contentx.io instead of www.contenx.io)

We only found out 2 days later, when we got our first comment saying:

"Why does your link say please purchase the domain"?

Posting the wrong video​

For some reason our posts on building my portfolio website with our figma-to-code tool did reasonably well, but all the attached videos were accidentally cropped to be 2 seconds long.

If the videos were not cropped, they would probably be able to do alot better

Track click through​

You need to know exactly how each post is performing and be able to compare them - by using a different tracking link for each platform you post on, you can see how your posts performs

Conclusion

Alot of people find their first users on reddit - see this video. When posting on reddit you must really ensure that your phrasing is not overly dramatic and salesy, and make sure you provide value to the community - otherwise you'll be downvoted and most likely banned.

All the best!

Why ideate?​

Over the 2 years that we've been working on the Figma plugin, we've heard a lot of feedback and suggestions about how we could better integrate FireJet into their workflow. Now that we are at satisfactory level in terms of addressing our main feedback (i.e. code quality), we are ready to explore other our users' suggestions on full-on Figma-to-code integration.

Customer Needs​

We've been reaching out and talking to developers and designers for two weeks now. And we have some made some learnings:

1. For simple websites, teams may use a no-code tool, but for complex web apps, coding from scratch is necessary. This is an absolute requirement.
2. Designers prefer to use Figma for their design work regardless of the type of project they are working on.
3. Designers often experience friction between design and code when the final product created by the developer does not closely resemble their original design.
4. Developers often have limited flexibility to make UI changes for the designer as they are typically occupied with implementing core features.
5. Developers generally dislike meetings.
6. Smaller companies strongly insist on using Figma for design purposes.
7. As companies grow larger (after series B funding), they start utilizing their own design systems.
8. Changes to design systems are typically initiated at the beginning of projects during monthly client meetings or user interviews.
9. Changes to design systems often involve updating existing components rather than creating new ones from scratch.

User Profile​

In the design-to-code space, there are 3 parties affected. From our learnings, here are their needs:

Product Manager / CPO / etc​

PMs spend a lot of their budget on hiring frontend developers to convert designs into code. They will look for tools to accelerate this process for their developers, especially if it can accelerate their product development time and/or reduce their development cost. They also talk frequently to their clients and customers, who often request changes to the product during the development process. These changes have a need to be done immediately. As such here are their needs:

Designers​

Designers are the creative brain of the project. They need the flexibility of Figma to turn their inspiration into reality over the constraints of no-code builders. Also as mentioned earlier, the final product rarely looks like their initial design. This is a pain point. As such, here are their needs:

Developers​

The brawn of the project, developers are always busy. Their primary task for design-to-code is the manual process of converting Figma designs into frontend code. They have specific requirements on the code generated based off the exisiting technology (i.e. frameworks, language, coding practices) they use.

As such, here is a breakdown of their needs:

Possible Solutions​

Ideal Workflow​

The ideal workflow for users is: Figma ⇋ Code

People intuitively expect the code to be in sync with their designs. But Figma is a designer-first tool that was never built for code conversion. As such, we have to come up with creative ways to get past this barrier. We've come up with several workflows:

Workflow 1 - Figma as the source of truth​

Your Figma is completely synced with an auto-generated design system. Any changes made to Figma components are updated in your code. There is a Figma plugin interface to handle responsivenes, component props, behaviours, and design system documentation.

Main Value Proposition: Saves the developer time in maintaining the design system

Steps:​

1. Designer creates design system in Figma (like you would in any other Figma project)
2. Designer adds in responsivenes, component props, behaviours, and documentation via an interface
3. A documentation page is automatically generated for the design system at a URL (e.g. abc-design-system.com)
4. Developer imports components from design system into code (e.g. yarn add @abc-design-system)

Workflow 2 - Design system as the source of truth​

Your design system stays as it is. You are able to import your design system components into your Figma project. When the code is generated, the algorithm uses the code from the original design system. There is also a Figma plugin interface to decide the variant and properties you want to set before you import.

Main Value Proposition: Almost zero design-code leakage means less back and forth between designer and developer

Steps:​

1. Designer imports design system into Figma plugin
2. Designer drags and drops the exisiting components into Figma as they see fit
3. Developer generates code to use as they see fit

Workflow 3 - Design ⇋ Code Platform with Import from Figma​

A design and code platform where design and code are in sync. You can edit designs to change the code. You can edit code to change the design. You can also import designs from Figma. It's literally a Figma with a code editor. This actually already exisits as our second product that is in beta: FireJet Sync. We just need to fix the bugs.

Main Value Proposition: Zero design-code leakage (if you keep your designs on the platform) means no more back and forth between designer and developer

Workflow 4 - Figma ⇋ Code conversion API​

Conversion API for converting Figma designs into code and vice versa. Teams can built their own custom implementation of solving their specific design-to-code problems using the conversion API.

Main Value Proposition: Full-flexibility on solution implementation

Designing a website or app is one thing, but turning that design into a functional website or app is another. That's where FireJet comes in. FireJet is a Figma plugin that allows designers to easily turn their designs into code with just a few clicks.

I just started using the FireJet plugin for Figma and I'm blown away by how well it works

- Lasven

How FireJet Works​

FireJet works by taking the design created in Figma and exporting it into a code format that can be used in various web development frameworks. This means that designers can focus on creating beautiful designs in Figma, and then easily turn those designs into functional websites or apps.

Features of FireJet​

FireJet has a number of features that make it a powerful tool for designers and developers alike. Some of the key features include:

• Support HTML output, as well as popular web development frameworks like React and Vue.js
• Export styles as CSS, Tailwind or as a JSON
• Importing existing styles from Tailwind CSS configuration files
• Automatic fixing of designs to optimize for code conversion

Benefits of FireJet​

One of the biggest benefits of FireJet is that it saves time and simplifies the design-to-code process. Instead of spending hours manually translating a design into code, designers can use FireJet to automate the process and focus on other aspects of the project.

Additionally, FireJet can help ensure that the code generated from the design is clean, efficient, and optimized for performance. This can save developers time and effort down the line, as they won't have to spend as much time optimizing the code themselves.

Conclusion​

Overall, FireJet is a powerful tool for designers and developers who want to simplify the design-to-code process. With its intuitive interface, customizable code templates, and support for popular web development frameworks, FireJet makes it easy to turn Figma designs into functional websites and apps. If you're a designer looking to streamline your workflow, or a developer looking to save time on coding, FireJet is definitely worth checking out.

Overview​

This article compares the most popular Figma to Code plugins in the market, and aims provides a comparison between each of them to help you decide which is the best for you depending on your requirements.

Note that this article was written by FireJet, and while we tried to remain as unbiased as possible, our opinions on code quality may differ from yours.

To get an unbiased overview of output code quality and output pixel perfection, use the interactive comparison to compare different outputs for yourself.

Interactive Comparison -->
Testing Methodology -->
Full Comparison Table -->
Raw Data -->

Full Comparison Table​

Go to full breakdown

Interactive Comparison​

Toggle Fullscreen

Test CaseTest 1 (Calendar)Test 2 (Code Card)Test 3 (PUBG)Test 4 (Dropdown)Test 5 (Frog)Test 6 (Landing Page)

Original
Figma Design

FireJetDhiWiseAnimaFigma to CodeLocofyQuestBuilder.ioTeleport HQ

Error while using plugin:



See 'Output Image' for full image of error message

FireJetDhiWiseAnimaFigma to CodeLocofyQuestBuilder.ioTeleport HQ

Error while using plugin:



See 'Output Image' for full image of error message

Best Code Output (Tailwind)​

🥇 1st place: FireJet
🥈 2nd place: Locofy
🥉 3rd place: Dhiwise

🥇 FireJet​

Pixel Perfection Score :

🥈 Locofy​

Pixel Perfection Score :

🥉 Dhiwise​

Pixel Perfection Score :

Best Code Output (CSS)​

🥇 1st place: FireJet
🥈 2nd place: TeleportHQ
🥉 3rd place: Anima

🥇 FireJet​

Pixel Perfection Score :

🥈 TeleportHQ​

Pixel Perfection Score :

🥉 Anima​

Pixel Perfection Score :

Best Features​

🥇 1st place: Locofy
🥈 2nd place: Anima

🥇 Locofy​

Locofy has the best features for further enhancing code outputs

Features:

• Design Optimiser
• Sync with GitHub
• Direct deploy to github, netlify, vercel
• UI library tagging (MUI, etc)
• Use live storybook components

🥈 Anima​

Anima has the second best features for further enhancing code outputs

Features:

• Direct deploy to netlify, vercel, aws, firebase
• UI library tagging (MUI, etc)
• Use live storybook components

Best Free Plugins​

🥇 1st place: TeleportHQ (CSS) / Locofy (Tailwind)
🥈 2nd place: Dhiwise

🥇 TeleportHQ (CSS) / Locofy (Tailwind)​

See Best Code Output (CSS) and Best Code Output (Tailwind) for explanation

🥈 Dhiwise​

See Best Code Output (CSS) and Best Code Output (Tailwind) for explanation

Testing Methodology​

Test Cases​

We tested 6 different figma designs and converted them to code using the various plugins. The tested designs are examples of real world designs used in actual applications

The designs selected also had complex styles applied to them in Figma, which makes converting these particular test cases particularly challenging for Figma-to-Code tools

You may get better results when converting simple designs/designs that are fully autolayout which is a requirement for several of the plugins tested.

However, we picked these designs in particular because real world designs tend to be harder to convert than toy examples.

Raw Test Case Data -->

Usability Scoring​

Usability Scoring is a subjective comparison between how easy each Figma to Code plugin is to use. See the full rationale for the scoring here

Code Quality Scoring​

Code quality scoring was done through a subjective comparison between different output codes given the same figma design.

Eventually we hope to let users rank which is their favourite code output to reduce the bias for the code scoring.

You can compare code quality yourself with the interactive comparison ->

Pixel Perfection Scoring​

Pixel Perfection scoring was done by converting designs using each figma to code plugin, and rendering the output code to see how well it matched the original design.

Scores were awarded as follows:

The results from each test case was scored and summed to give a final result out of 6

You can compare pixel perfection yourself with the interactive comparison -->

We're a team of custom web application developers who thought our frontend development process could be streamlined. Here's our story.