As we gear up for Figma config 2024, there are two exciting features that developers should be aware of: Dev Mode's new "Ready for dev" view and Code Connect. Let's dive into the technical details of these features and explore how they can streamline your development workflow.

1️⃣ Dev Mode ready for dev view​

The new "Ready for dev" view in Dev Mode is a game-changer for the developer handoff process. It addresses the iterative nature of design-to-development workflows by providing a centralized location for all designs marked as ready for development.

🎁 Key Features​

1. Centralized View: Access all "Ready for dev" designs in one place, eliminating the need to navigate through multiple pages or canvas areas.

2. Status Tracking: Easily identify the current state of designs with statuses like "Ready for dev," "Changed," and "Completed."

3. Filtering and Sorting: Quickly find relevant designs using filters and sort options:

   • Filter by: All, Ready, Completed
   • Sort by: Recent activity, Pages, Name (A-Z)

4. Focus View: Isolate specific designs for detailed inspection and access to version history.

🛠️ Technical Implementation:​

To leverage this feature in your workflow:

1. Open a Figma design file.
2. Click "Ready for dev" in the left sidebar.
3. Use the filtering and sorting options to manage the list of designs.
4. Click on a design to enter the focus view for detailed inspection.

This view is particularly useful for tracking changes, as it highlights when a design has been updated since the initial handoff. Developers can quickly identify which designs require attention and ensure they're working with the most up-to-date versions.

2️⃣ Code Connect​

Code Connect is a powerful new feature that bridges the gap between your component codebase and Figma. Currently in beta, it's available for Figma's Organization and Enterprise plans and requires either a Dev Mode or full Figma Design seat.

🎁 Key Features​

1. Direct Integration: Bring your design system component code directly into Figma's Dev Mode.
2. Real-world Code Snippets: Display actual code from your production codebase instead of autogenerated snippets.
3. Property Mapping: Map properties from your code to Figma, enabling dynamic and accurate code snippets.
4. Framework Support: Currently supports React and SwiftUI (beta).

🛠️ Technical Implementation​

Setting up Code Connect involves several steps:

1. Planning:

   • Identify your front-end framework requirements (React or SwiftUI).
   • Determine which components to integrate with Dev Mode.
   • Plan the configuration and component mappings.

2. Installation:

   • For React: Use npm to install the Code Connect package.
   • For SwiftUI: Clone the GitHub repository.

3. Component Mapping:

   • Map properties from your design system components to Figma properties.
   • This mapping allows Code Connect to generate accurate code snippets that reflect your component architecture.

4. Review and Iteration:

   • Test the Code Connect output in Dev Mode.
   • Collaborate with designers to ensure accurate representation and usability of component examples.

👇 Example Implementation (React):​

import { defineConfig } from '@figma/code-connect';

export default defineConfig({
  components: {
    Button: {
      importStatement: "import { Button } from '@your-design-system/react'",
      props: {
        label: {
          type: 'string',
          default: 'Button',
        },
        variant: {
          type: 'enum',
          options: ['primary', 'secondary', 'tertiary'],
          default: 'primary',
        },
        disabled: {
          type: 'boolean',
          default: false,
        },
      },
      render: (props) => `<Button
  variant="${props.variant}"
  disabled={${props.disabled}}
>
  ${props.label}
</Button>`,
    },
  },
});

This configuration defines a Button component with its import statement, props, and render function. Code Connect uses this information to generate accurate code snippets in Dev Mode.

📝 Conclusion​

By leveraging these new features, developers can significantly improve their workflow, reduce communication gaps with designers, and ensure more accurate implementation of design systems in their codebase. Remember, Code Connect is still in beta, so expect changes and improvements as Figma responds to user feedback.

Stay tuned for updates and expanded framework support in future releases.

👋 Introduction​

FireJet is a Figma to code tool that converts Figma designs into frontend code with one click. This saves frontend developers weeks to months of manually coding out Figma designs.

🤖 Agile Impacts​

Agile Impacts is an industry leader in impact measurement software, enabling companies to showcase their social and environmental impact. Their platform offers tools to create impact indicators, align with Sustainable Development Goals (SDGs), and generate detailed impact reports.

They serve impact investing funds, consultants, and startups, helping them streamline the impact assessment process, improve client engagement, and consolidate portfolio indicators. Agile Impacts aims to simplify impact measurement, making it accessible and efficient for businesses to demonstrate their contributions to stakeholders and investors.

Check out their website at https://agileimpacts.com

🧠 Challenges​

Manual Coding Overheads
Gorka's development team spent weeks to months manually converting Figma designs into frontend code, slowing down project timelines.

Consistency Issues
Ensuring consistent quality and structure in the generated code was difficult, especially for complex designs with various components.

Folder Structure Adaptation
Svelte/Kit's unique folder structure requirements added an additional layer of complexity, necessitating custom adjustments after code generation.

❤️ How FireJet Helped​

Using FireJet, Gorka was able to:

Reduce Development Time
The tool significantly cut down the time required to translate Figma designs into code, allowing the team to focus on more critical development tasks.

Improve Code Quality
FireJet generated clean, maintainable Svelte code, ensuring a consistent and professional standard across all projects. Adapt to Svelte/Kit

Despite initial folder structure discrepancies, the team found efficient ways to integrate FireJet's output into their Svelte/Kit projects. They also developed Python scripts to automate some of the conversion processes, further enhancing efficiency.

We have decided to continue using FireJet. In the coming months, we will be translating our Figma designs into Svelte + Svelte/Kit code, and we have found that FireJet is the best Figma plugin for this job. The Svelte code is good quality. We are long-term customers.

Gorka Llona, CTO, Agile Impacts

📝 Conclusion​

The integration of FireJet into Agile Impacts' workflow resulted in substantial improvements in productivity and code quality. The team could now handle larger volumes of design translations without compromising on timelines or standards.

FireJet has proven to be an invaluable asset for Agile Impacts, transforming their design-to-code process and enabling them to deliver high-quality frontend code swiftly. As they continue to leverage FireJet for future projects, Agile Impacts is poised to maintain its edge in the impact measurement software industry.

👀 Overview​

The biggest issue with Figma-to-code tools today is code quality. As a Figma-to-code plugin ourselves, we needed a way to measure the quality of the code generated, as well as see how we were faring against our competitors.

🧠 Using AI to compare code quality​

This report compares the top 5 most popular Figma to Code tools in the market to give a comparison between each of them to help you decide which is the best for you. For an unbiased result, the evaluation of said tools was done using 3rd party AI tools, namely GPT, Claude and Gemini.

Scroll To:

• Testing Methodology
  
• Interactive Comparison
  
• Code Evaluation Report
  
• Pricing Comparison
  
• TLDR
  

🔎 Testing Methodology​

We prompted GPT, Claude, and Gemini to compare the code generated from these tools based on key frontend development metrics.

Frameworks Chosen​

We picked React + Tailwind for the code output format. As of 2024, React is still the most used JavaScript framework of choice according to latest framework usage data from OSS Insight We also chose Tailwind for CSS styling, as it is alos the most popular CSS framework according to reports from State of CSS 2023.

AI Prompt​

You are a coding assistant who reviews code quality.
You must return a JSON output that follows the following schema:

// Schema was too long, go to the github above for the full schema

You must return the response in JSON format.

Open Source Code Quality Evaluation​

To make the process faster, we also made an npm package called codeqc to automate part of the process. You can find the npm package here and the GitHub repo here. Feel free to try it out yourself!

🧪 Test Cases​

To provide a good gauge of the average Figma design, we needed to test the products against fairly popular Figma designs. After thorough research, we went with Untitled UI one of the most popular Figma templates we could find in the Figma community library

🔗❖ Untitled UI - FREE Figma UI kit and design system v2.0

This template had 151,000 downloads, and 6,300 likes, making it a good test case for our analysis.

From this Figma template, we picked 2 common use cases (i.e. Login page and Pricing page).

📝 Frontend Code Metrics we used​

🖱️ Interactive Comparison​

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

Original Design	Generated Render
Generated Code (Sample)Full projects on Github

🤖 Code Evaluation Report with LLMs​

A separate table for each LLM was created. You can see a sample here For easier reading, we put in all the tables into GPT-4o to summarize all 6 tables into 2 tables by combining, averaging, and summarizing the table contents.

1️⃣ Test Case 1 Code Report​

We used a simple UI from UntitledUI as a control group.

2️⃣ Test Case 2 Code Report​

This UI was is more complex than the previous test case, providing a better representation of Figma-to-code conversion

💰 Pricing Comparison​

This segment isn't really part of the analysis, but I went ahead to the pricing pages of the Figma-to-code tools and summarized their pricing models so you don't have to.

TLDR - So which one should I use?​

In conclusion, our comprehensive analysis using third-party AI tools GPT, Claude, and Gemini, evaluated the code quality of five leading Figma-to-code tools.

The tools were assessed based on format and readability, component structure, responsiveness and styling, accessibility, code reusability, performance, and best practices.

FireJet emerged as one of the top contenders with strong scores across most categories, particularly in code readability and component structure.

Stay tuned for more code comparisons in the future.

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!

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.​

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)

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!

The promotional - sounding language in the above post is highly likely to get readers turned off and get you outright banned from several subreddits.

Here are some improvements I can think of:

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.

I won't say the list above is completely true, and I may have made mistakes in my observation of the market space. Feel free to reach out to me if you feel differently!

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