#236 - From Figma to Code: The Rise of Design Engineers (And Why It Matters Now) - Honey Mittal

[00:01:40] Introduction

Henry Suryawirawan: Hello. Welcome back to another new episode of the Tech Lead Journal podcast. Another in-person recording. This time, I have Honey Mittal with me today. He’s the CEO and co-founder of Locofy.ai. Interestingly, it’s a tool that can convert like design, maybe Figma design, into working front-end code. I think it’s always like a dream of many developers, you know, not having to build front-end UI and all that. So I’m very pleased to have you in the show today. And I hope to learn a lot about Locofy today. So welcome, Honey.

Honey Mittal: Thanks for having me, Henry. Yeah. Good to see this happening in Singapore.

[00:02:13] Career Turning Points

Henry Suryawirawan: Right. So Honey, I love to maybe understand a bit more about your background. So maybe looking back from your career, from your past history until now, would you share maybe any kind of learnings or key turning points that you had in your career that we can learn from you as well?

Honey Mittal: Yeah. absolutely. So I originally come from, uh, the north of India, near the Himalayas, but I’ve been now in Singapore 20 years. I came here to study at NUS. And I think, since you talk about turning points, I think for me the biggest turning point was the app store launch, because, uh, I was essentially building Windows mobile apps before the app store. I was an intern in Microsoft and I picked it up, .NET and everything, and I was building these apps to find location and post it on social media. And I think when the app store was launched, I think it was a big aha moment. That said, I was still, as a graduate, there were not many startups back in 2009 and 2010. So I was just building things for, yeah, just as a hobby.

But then I think when the Singapore startup scene kind of started getting a little bit more interesting around 2012-13, that’s where I think just like today, people are looking for AI, uh, you know, native engineers, product managers. Back then was more about mobile. And I was one of the few people who had actually built mobile apps in Singapore, no matter how scrappy and looking back at it, how not so good, you know, those apps were. But essentially I joined Wego.com and, uh, I think my career took off, I guess. Because, yeah, I was able to build my own mobile apps for a few thousand bucks, right? So joining a Series C startup, I had the budgets and I, but I brought that sort of early stage mentality into the startup.

The first engineer I hired in Wego is today my co-founder. So I think that was also a big turning point, just realizing that I got lucky in terms of hiring. And I started also realizing I was good at hiring maybe and attracting the right talent and seeing just what a 10x engineer meant and can do. And that kind of shaped what we are doing today as well. To your point, we were building, we built the first Editor’s Choice app on Google Play from Asia in 2014. Uh, and even the Google Play guys came down to Singapore and they were like, we can’t believe, I mean, you must have a hundred people engineering team. And I said, I have one engineer, who has never done mobile before. So I think through not just my learnings from my own sort of career, but also I leaned a lot on Sohaib, who’s my co-founder’s experience as well because he just went from gaming to mobile apps and just killed, kicked it out of the park.

Then we took over web of which we had no idea how to do and that became interesting. We launched the world’s first progressive web app, for travel especially. It was showcased at Google I/O, left, right, and center. And I think, um, that’s where my co-founder and I, our careers kind of grew really quickly. And we also started realizing that we are very passionate about building amazing experiences like, you know, irrespective of whether it’s mobile, tablet, which framework it is.

And that led to where we are today, uh, starting Locofy about four and a half years ago, was based on the last decade of experience and realizing a lot of companies and engineers either struggle with it or they see it as grunt work. Yet very few people can actually achieve amazing results. And that’s where Locofy was born.

[00:05:28] Transition from Developers to Product Management

Henry Suryawirawan: Right. So thanks for sharing, uh, some of the achievements, the highlights, your past experience. I think it was very cool when you mentioned that you published the first Google Play apps in the store, so I think, that’s, uh, really great. So I think you mentioned about Wego and I know that in your career you also went to FinAccel, right?

Honey Mittal: Yeah.

Henry Suryawirawan: Yeah. And also the other thing is, uh, Homage, right? So three startups. But, um, you mentioned in the beginning, you were building mobile apps, but then you turned into CPO actually, like product management and all that. So tell us this transition, what makes you transition to product management?

Honey Mittal: Yeah, so I actually started my career in Credit Suisse. And I realized very quickly that I’m not cut out to work in a large bank. But the good thing over there was I had free time and I was, I used to hustle a lot, right? So I was building my own apps and some people noticed at Credit Suisse. And they offered me to build something for Credit Suisse outta my free time. But I just realized how slow it was, and then I was like, okay, you know what? I’m gonna be a, I’m gonna work in a startup. So that was, I think, a very big turning point. But yeah, also I also said, you know, if I go to a startup, I’m not a 10 out of 10 or a 10x engineer. I’m maybe a seven or eight, and that was a long time ago.

And I just realized that what I was really naturally maybe good at, a lot of people started telling me about this, and I didn’t even know about it, was that, hey, you’re a really good product manager. And I was like, well, what’s a product manager? And the more I read about it, the more I started realizing that’s essentially what I want to do. And I set myself a goal that I, by the age of 30, I wanna be a product manager. I mean, of course back then, product managers would not just come outta straight out of college. It was expected for you to be an engineer for five, six years and then have some business sort of sense and spend time with designs.

So I set myself that goal and I got a job as a product manager with Wego, purely because of my experience with building mobile apps, being one of the early adopters of building apps. And, uh, because I think I was, I led that transformation from a .com to a mobile-first company for Wego, my career grew and I became a Chief Product Officer very, very quickly before the age of 30. And I just started realizing that’s where I can have the most impact. And I was good at, I think, identifying problems. And I’ve gotten better, um, as I’ve taken more and more challenging problems through Wego, FinAccel, Homage, and today Locofy.

So yeah, it was just product management happened because someone told me you’re a good product manager. And the more I read about it, yeah, it was just like, yeah, this is who I am. Uh, I come from a business family. So I naturally like ownership and solving problems. Yeah, I just started realizing if I can attract the best engineers, which I was able to do in the early in my career, I started realizing that I can have big impact in companies owning decisions and owning that, you know, engineering execution essentially.

Henry Suryawirawan: Right. Very inspiring. I think for people who sometimes felt that, I dunno. For example, if you are an engineer and you feel that engineering is not your world, right? It’s worth to take a plunge and try out, maybe in this case, it’s product management. And especially if you have feedback from people telling you, hey, you are good at in this area as well, right? So I think it’s very inspiring to see that someone can transform their career. Even setting aside a goal, right, to achieve the role.

Honey Mittal: I think that’s where that comes through family upbringing, I think basically, right? Like the way I grew up was basically just say yes and then figure it out, right? I think that helped me adapt. And I still feel that, yeah, for any young listeners who feel they’ve done a degree and they don’t necessarily enjoy it. If you’re young, just try everything. And I’ve talked to a lot of folks who say, should I do an MBA and then get into product management? And I’m like, no. Just build something. Even if it doesn’t work out. Even if it’s, you know, that doesn’t go beyond a few hundred users, it’ll teach you what product management really is that you cannot learn from a book or from just lectures. So yeah, absolutely, any young people or even, uh, mid-career, I would say in this AI age today, it’s becoming easier to find the resources and the tools to pick up new skills and new job descriptions. And job descriptions are getting transformed as you obviously know. So yeah. That’s something I still stand by.

Henry Suryawirawan: Nice. So yeah, I think trying, experimenting, failing, I think it’s part of the learning journey and the part of the growth, right? I mean, yeah, it could fail, I mean, but it could also succeed just like what you had.

[00:09:53] The Key Product Lessons from Working at Major Startups

Henry Suryawirawan: So you mentioned that you have worked in these three, I would say they are like big major startups, right? Maybe more scale ups rather than, you know, tiny startups. So what are the key lessons, if you can pick, you know, as a product, like a CPO or product manager, what are key lessons that you learn about building product, like great products from these various three companies that you have?

Honey Mittal: I think product management… In the last five to seven years, I’ve seen a lot of young PMs saying product management is about gathering requirements, writing PRDs. Uh, it’s not. It’s just not. So I think for me, product management is about solving tough problems. Uh, and in this case, because we are a part of the tech industry, it’s about solving, you know, tough problems that can be solved very efficiently and have massive impact through tech.

So I think for me, the biggest learning has been throughout my career just how to identify the right problems. Because when you have good engineers, there is no shortage of a, for a company to, you know, like in a company to build applications and automations, but not everything is worth it. So I think you always have to keep an eye on a) understanding what impact means, b) I guess identifying the biggest problems, which is like one and two are loosely related. And then just building as fast as possible. I’ve never believed in documentation, which has, uh, maybe pissed off a few people that I’ve worked with in the past. But I always believe, I think just once you know a problem is worth solving, just go build it as quickly as possible. Take some shortcuts if you have to because it’s still a hypothesis at that point of time. And you want to learn whether you’re on the right path as quickly as possible. And then kind of course correct before going too big into like, here’s my problem and I’m gonna spend two years before I get any feedback from the, from users.

And number two for me. Another learning was I think asking your users for what they want and surveying them and feedbacking is actually overrated. I think sometimes people don’t know what they… well, they might know what they want, but they may not necessarily know that beyond their, you know, needs, there are certain things that can actually have a much bigger impact. And the only way to find out is if you build. Like for example, in 2007-8, if you ask mobile phone users, what do you want? They would’ve said a slightly faster, slightly slimmer, more memory, more songs. And then no one would’ve said, I want an iPhone. You know, like a smartphone and like no keyboard on it and there’s an app store around it. So I think that’s what I’ve realized that spending time asking users for feedback and hoping that will give you the answer is a bit overrated.

People sometimes just say yes because there’s no cost to saying, hey, would you, if I build something like this, would you use it? People are like, yeah, sure. And then you spend six, nine months building it and no one uses it. So I think you just have to become better at reading all the data points around you and using your gut instinct as well. And the more you build, your gut gets stronger, obviously. But choosing the problem is, I would say, the more important part of product management than, you know, gathering requirements and documenting it. And I think in the AI age as writing PRDs and, you know, doing services becoming easier, a product manager’s job is now even more about identifying the right problems where you may not even have the data, or you have the data, but it doesn’t necessarily point you towards, hey, go and do this. So I think that’s where a product manager should be first a problem solver, and problem solving requires to you choose the right problems and then solve it the right way. So, yeah, go down to the basics, basically.

Henry Suryawirawan: Right. I think very good key points that you mentioned. So first, of course, you need to identify the problems that you wanna solve, understand the impact, right? So problems and impact kind of like correlate each other. So you want to solve bigger impact problem, I would say, and not like small impact problems. And then, uh, obviously build fast, uh, as much as necessarily validated with users. Sometimes use your gut. I think I remember when you mentioned about this, I remember Henry Ford’s quote, right? So if I ask people what they wanted back then, they wanted like a faster horse, not a car. So I think that, uh, reminded me of that quote.

[00:14:12] Learnings from Locofy Product Pivot Journey

Henry Suryawirawan: So throughout those three key experiences, do you have an example where you actually have to pivot? So for example, from, okay, I identify this is the problem I wanna build, but over the time after you release it maybe or get feedback from users, you actually have to pivot solving slightly more tangential problems. So is there such examples that you can share maybe?

Honey Mittal: Uh, yeah. I think the most recent one I would say was uh, around Locofy itself. So when we started Locofy, I think we were very clear that design-to-code is a big problem. And I think, look, today, it’s quite hot, I would say, and everyone agrees with it. But back in 2021, early pre-ChatGPT, pre-Stable Diffusion, pre-Copilot, to think you can go from design to code was considered a little bit crazy. And my co-founder and I were also a little bit, uh, naive in thinking we can do it for any design tool to any code framework very quickly. Doing the first step, building the MVP is easier. Getting it into production is super difficult. Uh, and it takes a lot of investment obviously, and a lot of focus.

So I think for us, the pivot started from… we were app builders, right? So we were like, let’s do building iOS apps and Android apps can be easy from designs or from design tools. And we had to almost like say, hey, do we build our own design tool in this case? No, let’s not like reinvent the wheel. We will go with a existing design tool.

And we did a simple website where people could sign up and we just started realizing just how big, not only web was, but also I think it was a turning point of, you know, web-based mobile app frameworks. Like, you know, obviously Flutter, React Native becoming a lot more popular. And we said, ah, it’s okay. Let’s just do web first and maybe in six months, we’ll do Native iOS and Android. Four and a half years later today, we still haven’t started working on it. Just because I think once you launch something, so to my point earlier about like, you know, surveys and asking users, that was more about like doing something before you build. But once you solve, once you kind of like launch your core problems first prototype or MVP after that I think we just got so much feedback, that our path became a lot more clear that we are going to build a… we are going to be a web first, uh, you know, design-to-code platform, front-end development platform, rather than just like app building that we initially thought about. And of course we will go and build that. But that was the first major sort of pivot.

Second one was we, even though we were clear AI will play a big role. The early few prototypes in the first few MVPs and all was a lot of heuristics. And there were engineers in the teams who believed that you can solve this problem with heuristics. But I think we started seeing patterns and then we started building our own, uh, design models. The way and how quickly that has happened and now how much of our, not just revenue, but the core product sort of depends on it, I would not have anticipated or predicted that. Four and a half years back, we thought AI would play a support role. You know, like some basic tasks of going from design to code, picking up assets, making them work across different browsers, making them work across different sort of form factors. Maybe identifying some buttons and inputs. But today, it’s like one click basically to go from design to code. And that has, that looks completely different from what we initially thought in the early days. And I think that’s where that feedback of having something out in the open is a lot more valuable than asking people through like a form itself. Yeah.

Henry Suryawirawan: Again, like, uh, I think everyone who has built product would have the same opinion, I would say, right? Because once you throw something out in the market, right, the market will kind of determine exactly what products, and I think you will pivot along the way, right? So I think I’ve heard a lot of product companies that turn to successful, right? The initial story is kind of like different from what they’re doing now.

Honey Mittal: Oh, yeah. I mean, one more thing that I forgot to mention is when we started the company we said we’ll never do enterprise. Like we will just be a bunch of engineers, product managers, you know, like have a $20 subscription. And you know how every everyone starts, right? Like I just need a million people buying a $20 subscription and never have a sales person. But today, we are fully enterprise. Like 90% of our business is enterprise. And, yeah, we just started realizing, I think I would say early to mid last year that enterprises or enterprise engineers were using Locofy in free beta. They started asking us, hey, we love Locofy, but we can’t use it in production in the company because we need a security audit and like, you need to have a proper pricing. We can’t use free tools. And initially, we kept saying, sorry, no, we don’t even have a salesperson, right? Like, whatever, you can use a tool for free. If not, no problems.

And as we started benchmarking things across individual developers and enterprises, it just hit us on our face and we are like, we are an enterprise company whether we like it or not. The data suggests so, qualitative and quantitative. And today we are like a fully enterprise company. One and a half years ago, I actually told some investors I’ll never do enterprise. And today, they’re like, wait, what happened? So which is just part and parcel of obviously building a startup, right? Like you can have an end-goal in mind, but the, like the path you take to get there will never be a straight line.

[00:19:36] An Introduction to Locofy

Henry Suryawirawan: So I think this is also a good segue for people who haven’t heard about Locofy. I think we have mentioned some interesting pivots that you’ve done with Locofy. But in the first place, maybe if you can explain what Locofy is. Like what kind of proposition that it has or what is the cool thing about Locofy?

Honey Mittal: Yeah. I mean, in very simple terms, part of the product development journey, when you build a website or mobile app or dashboards or anything internal, external is, uh, you know, you spec out something, you design it in simple terms, and then those designs are obviously done on tools like Figma, which is very popular. There are other examples like Sketch, Adobe XD from a decade ago, Penpot for open source community. And these designs are done by designers. And then once, let’s say, the stakeholders have kind of agreed to the design, it goes to engineers. Engineers, very, very, like simplifying, I guess it’s just front-end, back-end engineers. Let’s say front-end guys are more focused on bringing your designs to life through code and back-end engineers build everything. Infrastructure, back-end, servers, and security. And the list is obviously very long. We only focus on the automation of front-end itself, because we’ve seen in like a decade plus of our experience that as much as front-end development seems easy or designs ready, why not just have it ready in a couple of days, it’s where 60 to 70% of our time and our best engineer’s time was going. And yeah, so we just thought let’s automate as much of that as possible directly from the design. So in short, Locofy converts your existing Figma designs and Penpot designs and Adobe XD designs into whichever sort of front-end framework. React, Angular, Vue, HTML, CSS, Flutter, React Native, pretty much anything.

And uh, how it does that is we build our own proprietary technology. We call it the large design models. Because LLMs actually don’t solve this problem. So we kind of trained our own models, deep learning techniques to go from designs to front-end code. We are not a no-code app. A lot of people think we are a no-code app builder. We are not. We are a low-code builder. We give you the code, but that’s not complete. It’s not the full app, obviously. You have to then go and refine it further and potentially like add, you know, your APIs and back-end logic. So we, Locofy is essentially a tool for front-end engineers, full stack engineers, anyone who’s actually involved in building the front-end to cut the time by 60, 70, 80% by going from designs to a pixel perfect, developer friendly, you know, uh, responsive and interactive, uh, replica of that design rather than having to build it from scratch.

Once you get that code, we have integrations into, you know, the Cursor of the world into GitHub, VS Code, uh, so that you can easily pull that code and keep merging it and integrate it continuously, uh, beyond that point. Yeah. So what we stand for is building amazing experiences with less effort and freeing up designers from, engineers especially, from grunt work of writing UI code from scratch. And letting them focus on the tougher front-end and back-end problems, yeah.

[00:22:40] The Story Behind The “Locofy” Name

Henry Suryawirawan: Right. Maybe a bit of trivia, I would assume Locofy here stands for low-code-ify? Is that correct?

Honey Mittal: Yes. we were, when we started the company, I think low-code, no-code was still a kind of nascent industry. And when I said we are gonna do design-to-code, uh, to one of my investors, he is like, oh, low-code. And I was like, what is that term? I’ve never heard of it. So I started researching and I think low-code became like, for a couple of weeks we were just saying low code so much that loco started becoming a little bit of a possibility. And like loco.ai would be nice. And it’s a kind of crazy that we are doing a startup, and loco obviously means crazy. So it’s… We look for loco.ai, but someone had it. And then we were like, hey, Shopify is pretty big. And there was this trend of like adding -ify in the end of everything. So we just call it Locofy.

Henry Suryawirawan: I see. Okay. I like that thinking process.

[00:23:27] How Locofy Generates Pixel Perfect & Accurate Codex

Henry Suryawirawan: So obviously, it’s very promising, right? Everyone who has seen Locofy website, I assume, they will be thrilled, right? Oh, from sketches you can turn it into code, right? And you mentioned pixel perfect. But how much pixel perfect it is? Because sketch can be anything, right. From your visuals, colors, you know, maybe even animation, I dunno, into code. How much? Like is it 100% accurate, or is it like, how much?

Honey Mittal: That’s an amazing observation, you are obviously an engineer. So currently, about 80 to 85% of screens that are converted using Locofy do a 95% plus pixel-perfect representation. We basically look at every node, every layer, uh, once we render the code that Locofy produces and then we match it against the design to see how many of those elements have moved or don’t look the same. But yeah, how easy is it is a different story because that depends a lot on how your designs have been structured. And to your point, right, like designs can be anything. And Figma became popular because of freeform. Like, you know, people can coordinate and like work together, multi collaborate. Sorry, multiple people can collaborate and build a design together.

But there was no real importance, I think, in the past about how you structure those Figma layers and nodes. Whether you belong to the 80, 85% of accurate code, pixel-perfect code or not depends on not just how beautiful your designs are, more how they’re structured. And especially to do with like, you know, removing unnecessary layers and nodes. Grouping things properly so that there’s a relationship between them using best practices like auto layout. Naming your layers properly. If you do that, then the chances are you’ll save 70 to 80% of your time.

As we continuously see with our enterprise customers, when we go and train them, before we even train them on how to use Locofy, we first train them on how to structure your design, setting up your design files. Just like any AI, right? Like the input and output are related to each other. And if garbage goes in, then garbage comes out. So I think that’s where Locofy does a tremendous job with people who are either already following the best practices on their Figma designs or Sketch designs. Or for the folks who say, this is a big enough problem, I can invest a little bit time upfront. Maybe half a day of my designer’s time can save me four days of my engineer’s time. That obviously equation is, quite hard to say no to. So it really depends on the input itself.

And then the second part of it depends on how our models have been created. We spent about four years building our design models from scratch. And they’re a combination of, people mistake them for, so which LLMs are you using? The answer is it’s a completely different architecture. It’s not based on language. It’s based on visual understanding of designs. So whether it’s to do with the design structure, whether it’s to do with identifying, you know, HTML elements, uh, interactive elements, buttons, input tags, hundreds of them. Identifying the libraries, right, because you could be using Material and Bootstrap or your own design system. Then responsiveness, which is one of the toughest problems that again, goes back to how well your designs are structured. How it behaves on mobile, desktop, and tablet. Relationships have to be formed and identified between each element on your desktop website for it to work.

So it really comes down to the quality of input and that’s why we are doing really well with enterprises, I would say, more than the individual engineers today. Because individual engineers like things to just happen very fast. And then they also don’t wanna go into designs and structure those designs. Whereas in enterprises, we talk to teams together and we organize the trainings and workshops, which enterprises are used to. They see massive benefits of investing some time into designs, because their roadblock is never design. It’s always engineering. Whereas in young startups, I think, engineers, like I said, don’t wanna go into Figma design and change things.

And, uh, yeah, until they do that, they won’t just, they won’t save any time. And, most of them will say, I can do this page in two days myself. If I have to then invest an hour finding who the designer is, convince them to make the changes, then it doesn’t work. Whereas in enterprises, we talk to teams where it works out because there’s a common denominator. Generally, the VP of Design, VP of Engineering, who sees the benefit of doing this.

[00:28:01] Why Locofy Pivoted to Focus on Enterprises

Henry Suryawirawan: Wow, I think that’s very a great insight, right? Because yeah, like, now that you mentioned it, of course, if you are a few people startup, right? You don’t have proper Figma design and all that. So yeah, I think that perfectly makes sense why you go into enterprise, right? Or like a bigger technologies organization set up, I would say, where you have designers and engineers, right?

Honey Mittal: That one learning was, I would say, the biggest reason for our pivot towards enterprises. Because initially, we were like, yeah, people will just do designs properly. And we do a demo, and people are like, oh, this is great, but when I tried on my design, it doesn’t work. And we say, oh, when we investigate, your design files are not done in a certain way. And then we would do videos and we do trainings and workshops and everything, but individual engineers, they don’t like to do all of this, maybe.

But with enterprises, we started realizing that when we were running an open beta, the larger teams would take interests, would come in like groups of 10. We would run like a one hour workshop and then they would start reporting that they’re saving a lot of time. And we started just realizing there’s a clear sign over here that larger enterprises are okay investing their time upfront, because they have the designer, engineers all together. And we, for a long time, we thought Figma itself would, you know, launch tools to optimize designs and they did in pieces here and there. We partnered with them, we gave them that feedback as well. But yeah, it still remains to be one of the biggest problems with design-to-code, right? People who expect it to work like magic will very likely be disappointed. But folks who’ve invested the time into the prerequisites have seen massive improvements and massive like time saving overall.

[00:29:39] The Locofy’s Code Generation Process

Henry Suryawirawan: Right. so that means like, uh, after hearing what you explained, right, definitely, it doesn’t just use like a visual analysis, right? It also analyze like the Figma design itself, the metadata, the structure and all that. And then, uh, you also mentioned that the team most likely has a designer and engineering setup, right? So that typical setup. But one question, uh, remains. You mentioned about, you know, maybe 70%, 80% reduction. How long does it take, like for me to submit Figma files, or click one button? How long does it take for you to generate?

Honey Mittal: The code itself? Yeah. I mean, not more than 20 to 30 seconds.

Henry Suryawirawan: Wow, okay.

Honey Mittal: And you can select even three or four screens in the same go. We have customers who have built large projects of thousand plus screens in a matter of months using Locofy. And I think, um, in the background, there’s just maybe like seven to 10 different models running. One is to optimize a design. One goes and finds those HTML elements. The other one goes and looks for responsiveness. And another one says, hey, let me find all the libraries and custom components you have. The other one says, hey, there’s some repetition. Let me break your design into smaller, reusable components. The other one goes and breaks it into what are the props, for example. But all of these happen in parallel and they never take more than a few seconds, actually. Yeah.

The time is actually spent on the pre-Locofy. So like I said again, right? You invest half an hour into cleaning up your design the right way. Locofy itself doesn’t take much time. And of course, like the beyond the initial code generation, it’ll make some mistakes. So we provide editor tools where you probably spend another half a day or whatever. But yeah. The equation that we have seen with some of our customers reporting back numbers is that an engineer who was able to do, you know, 10 designs or 10 screens per month is now able to do 25 to 30 after the initial sort of learning curve. But yeah, we wanna bring it down, obviously, even, uh, even more.

I don’t think people complain about the 20-30 seconds it takes. It really comes down to the initial code that gets generated. If it’s too far away from what you have in mind, you’re not gonna invest the 20% time to make it better. So it really comes down to doing all the pre-checks and everything. And that’s why we are innovating a lot more right now, because we are realizing that it’s still 9 out 10 organizations are not really doing designs a certain way. And we are teaching them, but we can also automate that part as well. Yeah.

[00:32:13] Why Locofy Built Its Own Large Design Model

Henry Suryawirawan: Nice. So you mentioned in the beginning about building this model, right? And I think four and a half years ago, LLM was not the craze as we have now. So basically your path is actually really like building the traditional ML, right? Like using neural network and all that. So tell us about, the decision, the rationale, why you need to build your own model. And after the LLM comes in, do you even try, you know, using the LLM that whether it can solve the problem?

Honey Mittal: The evolution. So we launched our first beta product in 2022 Jan. And in there, we had a very simple model. Well, okay, the first initial alpha version is you would have to select, let’s say a button in the design and say this is a button, and then add its properties. And then select one other one. Because your human eyes can look at a rectangle that says “Buy Now”. And anyone can say that’s a button, but it’s just a designer’s vector that constitutes a button. The engineer would still have to write the code for it. So we said, okay, let’s make it this way. The designer or the engineer just selects that rectangle and say, this is a button and we will automate the code for that.

We started doing that and we realized, hey, you know what? We have a lot of data. Can we train maybe like an image-based model or a CNN to understand? Because I mean, if it’s a rectangle, it can be a button, input, daytime picker. All of them have a text and an icon and a rectangle. But if we have enough data and we can kind of like train certain of, these CNNs and transformers were kind of new back then as well, maybe we can get some results.

And in the initial days, we were like, ah, it’s kind of doing the job. It spits out and says it’s a button or input or daytime picker. But you know, that’s already better than asking a user to do it manually. So it was initially in our v1, it was more of a auto suggest. You select a rectangle or a Figma node and we’ll say, hey, we think this is a button, 80% sure about it, but it could also be a datetime picker, which is like 60%. And they just had to say yes or no, right?

So that’s how we started doing it. And the more our customers did it, and in free beta, we told our users as well that we are going to use this data anonymized to train our models. The more we started doing that, the more we are like, hey, if we are hitting 90% accuracy, do we even need to suggest? Can we just not go and do it? So that was the first sort of AI that we started building on. It was purely for tagging. Understanding buttons input, datetime pickers, switches, you know, headers, footers.

The second one came around design optimizations where we started realizing that we have to remove these unnecessary layers and groups and nodes. We started seeing some patterns and we said, hey, there are certain graph neural networks that can potentially help over here. Another one was, uh, around… These were just like three or four different models for very specific things. We saw patterns with our customer’s data and talking to them as well.

Another one was in the design, the designer says frame one, frame two, frame three. But in the actual design, it’s maybe like a carousel. So in code, you don’t wanna call it frame one, frame two, frame three, you wanna call it something else more useful. So for that, before ChatGPT was launched, actually, we were using OpenAI, right? So we’d heard of transformer models and we were, there were a bunch of APIs we could call at that point of time. So we started sending this information and saying, frame one, frame two, frame three, and this is the image. Tell me what this could be. And they come back and say, this could be a, actually a city card. Or it could be like a country carousel, whatever. We started naming the layers properly using that.

And the more we started like building our own, sort of training our own models, different techniques, like we use a combination of transformer models, obviously, uh, sequence to sequence, YOLO, XGBoost, tons of them. And it was all experimental. There was a hypothesis that, look, this is all more image based or maybe give it like a CNN sort of a thing. And the more we started automating these smaller tasks, we started realizing that a user who clicks hundreds of times to go from design to code, maybe 80 of them, we can just go ahead and do it for them. And then instead of asking them to do it manually and learn from it only, we just go ahead and do it and then give them editor tools and see which ones they change. Which ones are not right. And that helped us also learn slightly faster and made the experience tremendously better.

As we were launching this, ChatGPT launched. And we started hearing this term LLMs. And we are like, great, like if it can help us with the design to code, great, because we are not like a, we are not in the business of building a model and competing. We wanna solve front-end engineering, design-to-code problem. But the more we looked at LLMs, the more we realized the LLM architecture itself makes it super hard, if not impossible, to fine tune it or to prompt it to understand Figma designs. Because it’s not built, I mean, it’s built on understanding language and trying to predict the next word. Yeah, there’s a certain structure to that. For designs, it’s completely free form. Just because there’s a button doesn’t mean necessarily it’ll always be next to a carousel or next to a header. Uh, LLMs struggled to understand that, but LLM solved some parts of the problem. So we are like, okay, we, the majority of understanding designs, we have to build our own design models, but we’ll use LLMs as and when we can use them and we continue doing so even today.

But in our case, going from design to code is about, I would say 80 to 85% of it, is how well we build these specialized models, uh, using, you know, any techniques really, and combine them together with LLMs. So for example, you go from design to code, LLMs may not understand designs very well. But once we spit out the code, LLMs actually understand code really well. So if I give, if Locofy gives out the code for a form that looks like a flight search form, we could actually ask an LLM to write the logic for it. And that’s where we started saying, okay, you know what? Design to code is not just a matter of like click a button, get the code and go on with it. It’s more about reducing 80% of the more, you know, things that can be automated where we can see a pattern, get it to code, and then see what LLMs can do with it. Potentially build our own vibe coding functionality. But then we started saying, hey, there’s a MCP protocol. Like, you know, it’s kind of becoming bigger. And the likes of Cursor, Windsurf are already investing so much with amazing minds to add functionality, code reviews, all the non-UI part. Then maybe that’s the best marriage possible, right? Design to code with Locofy, and from code to more functionality and everything with LLMs.

So the way we look at it is, rather than say LLMs or not, we think about what would an engineer do with at this step? Can we automate some parts of that problem? To automate that part of the problem, is it an LLM that can do it or our own models? And we go and build that rather than just say we are just gonna build an LLM, vibe coding tool because it’s hot right now. So it’s about breaking the problem into sub problems and seeing where, what fits.

Henry Suryawirawan: Wow. So thanks for sharing all this. I dunno how much is proprietary, but I think we get a peek into internal..

Honey Mittal: We actually have written a research paper about it. It’s public, so yeah. So the design model part is proprietary, but we are very open about sharing how we build them, yeah.

[00:39:25] Locofy Integration with Existing Development Tools

Henry Suryawirawan: Nice. So maybe a little bit, uh, diving slightly deeper, right? So when you mentioned you help front-end engineering to come up with, uh, I don’t know, like the first draft of the code, I assume, right? So, what was the stop? Like you produce a code, you have the visual elements, UI elements and all that, I assume. Then you have a hook points, I guess, like where the developers now come in to put it in logic. Or do you also fill in the logic and, you know, integrate with something, you know?

Honey Mittal: No, current- First version was just we give you the code, you export it, and gone. Then we build a web app where you could view the code and you can kind of added some editor tools for you to change a few things. Then we started realizing that our customers, what do they do after they download the code? They figure out a way to open it in VS Code and add functionality. So we built a VS Code extension where with one command you can just pull that code and continue working on the code that Locofy produces. And lately, obviously with the Cursor and everything, we have an MCP where you can just convert a design to code, go to Cursor and say, hey, using my Locofy MCP, pull that code that I’ve generated for my flight homepage, add accessibility, clean it up, make the carousel functional. So that does beyond the front-end itself.

And we have integrations to GitHub as well because you may be just building a small component or a section and push it directly to the right repo. And we then build a way for you to do continuous integration. So if you change something on the design, Locofy will identify that change and you will still make the choice of whether you want to just auto merge it or replace the older version of the code and kinda give you a three-way editor on GitHub to also select. So you can kind of keep going back because designs keep changing a lot.

We are considering whether there are still some parts that we can do an LLM integration on the code that is generated before it goes into VS Code and other places where it’s purely related to the UI that we can provide more tools, and maybe an LLM integration. But yeah, that’s still something in the works. So we do only front-end and we make sure that that code is connected to your design system, connected to your designs, connected to your code repo and your developer tools, to provide like a very seamless way of not just doing it one time, but also coming back to it again and again.

Henry Suryawirawan: Yeah, I think the cycle, the loop here is very cool, right? Because, uh, many people would just assume like, okay, you turn into code and that’s it. You just, you know, take it and, you know, transform things. But we know that design change, you know, sometimes, uh, user feedback gives, uh, like a certain, I dunno, changes to the design, right? And you have to iterate, right? I think it’s really cool that you have all these integration points.

Honey Mittal: Yeah. So for example, like, you know, merging code is something LLMs are amazing at. And that’s why we use LLMs. Adding accessibility, we like, rather than we build a feature, actually LLMs do a really good job at it. Like we said earlier, right, like we see it as a end-to-end problem of automating front-end. Whether it requires us to build it using our proprietary models or LLMs, we don’t necessarily care. So if LLMs get better at it, good for us, why build something that will be anyway, base model is already better than what we are spending six months on. But we also know LLMs cannot understand designs the same way it can understand legal jargon and, you know, create something from scratch itself. Yeah.

[00:42:44] LLM Strengths and Weaknessexs

Henry Suryawirawan: So definitely I think people who have heard this will be very interested, especially front-end engineers, right? We are always very lazy translating, you know, design into code. You mentioned about, you know, what LLM is good at and what LLM is not good at. For other people who are also solving maybe a slightly similar problem where they think maybe LLM can solve the problem, but not quite right. What’s the tipping point where you see like LLM is good at what, and LLM is not good at what? Maybe can give some suggestions based on your experience.

Honey Mittal: Look, I won’t claim to say I can make you a list of things it’s not good at and things it is good at. But we understand obviously our space the most. And the answer lies to experimentation, right? Like if you think your problem can be solved with LLMs or can’t be, for that matter, best to just run some experiments and see what it may be. You might get surprised by how good it is in some things that you never thought were possible and vice versa as well. And I think for us, the more we study LLMs in the underlying architecture itself and how it works, how does like this technology work. When I asked ChatGPT to do something, how does it even, what does it even follow? What technology it’s built on? I think that’s where we realized and we were like, there’s absolutely no reason why a design would follow the same patterns as a research paper or code or books or tweets or posts, which is where LLMs shine and that’s what it was built for.

But I think just purely based on that knowledge itself, if you’re building, let’s say a legaltech company, LLMs will obviously do really well, wherever the, there’s the, you know, language and text and sentence structure plays a big role, LLMs are obviously amazing. In the design context, they’re still good in terms of producing patterns that have been built in the past. So asking an LLM to, for example, design a wallet. It can design a wallet for you, because there are hundreds of wallets in the world and it’s been trained on all of them.

But if you design that same wallet in Figma, the input changes completely. It’s actually a json format. I mean, you obviously know how Figma nodes and layers structures work. That’s where LLMs are just not made to understand that sort of parent child hierarchy that looks more like a graph than like a sentence itself. Or that’s at least our understanding of it, right? So, yeah, I mean. But at the same time, like I’ve seen folks doing really, really well… Essentially, copywriting anything around marketing, creating images, LLMs are obviously amazing. Using the agentic sort of frameworks, you’re starting to see a lot more of these menial tasks of going from one tab, selecting for something on your website, clicking it and buying it for you, but solving fundamental problems that require a different mindset or a different architecture than LLMs, of course, it can’t. The newer models are starting to do specific things decently well. We can fine tune, for example, an LLM today to make it understand the relationship between parent, child and child up to a level of N-3. Anything beyond that, we see the results are quite crazy or super expensive, super slow.

So I think in the context of design-to-code, I can just say that LLMs work for, let’s say, understanding naming, potentially changing the code from, let’s say React to Angular. But then understanding designs itself is something where it struggles. Yet a lot of people are still, I think using, they’re going in with the hopes of like LLMs to solve every goddamn problem in the world. So let me just try it. And it maybe works with some basic websites, but that’s why we are hearing from our customers as well that it doesn’t understand it. We have copyright issues on top of that. We are not necessarily sure if it produces that wallet, can someone claim it was their wallet design that, you know, our large company that cares about its reputation will be obviously against?

So yeah, I would say it really depends, man. It depends on the problem you are solving. Do experiments. Don’t put all your eggs in just the LLM basket. And in most times, what you realize is it solves some problems. And then that’s where the quality of how you fine tune it. But also fill that last mile gap, let’s say, by building your own either heuristics or, you know, deep learning techniques. I think that’s where the future of solving problems with LLMs is gonna be. That the initial POC and all looks very easy with the LLM. But as you go deeper, you have to build, you know, models around it or wrappers around it to kind of get the results.

I’m not sure if I answer this question very well actually, because, um, yeah. It’s just evolving so quickly. But also I think there’s a lot more chatter now about the limitations of LLMs around the world. It doesn’t understand how humans think how the world works. And that’s why I think there’s a lot of chatter around how LLMs cannot alone solve AGI, for example, and we have to think of a completely new way rather than just think scaling laws, just give the LLM as much information and more compute and it’ll get better. There’s recently news about even to get marginal, marginal improvements on LLM accuracy, you’ll have to get 10 to the power a hundred, you know, that much sort of source of energy to even get that marginal improvement, which Earth even doesn’t have. So I think, yeah, LLMs are going to start hitting a wall or rather ceiling. For us, we hit that ceiling a long time ago with design to code. But I think a lot of other startups that are betting big on it will find through their own experiments, which we are not very well obviously aware of.

Henry Suryawirawan: Right. Yeah. So I think, uh, from various conversations I had with, you know, people who are expert on AI, so they also think that using the current LLM transformer approach may not be the path to AGI. But I mean, who knows? Like this field, you know, changes so rapidly. Every few days we will see new advancements. But yeah, thanks for sharing your perspective.

[00:48:47] Other Challenges Building Locofy

Henry Suryawirawan: So I assume building the large design model is partly one of the most complex engineering tasks that you have. Is there any other thing that is un-intuitively, complex as well for us to, you know, maybe learn about from, from your experience?

Honey Mittal: Yeah. I guess I’ve already touched upon it. But right now, I think the biggest problem in the design-to-code space, not just for Locofy, and the biggest opportunity as well, while there’s a lot of chatter around, hey, designer, not only designers, but anyone can design. And do you even need Figma? You can just go to Lovable, Bolt and just design something. It’s absolutely true. It solves a lot of use cases. But we still think, we obviously have a strong bias towards advanced production products will require proper designs and not just an LLM producing the same results that your competitor can get as well. It is becoming commoditized. And what happens when everyone has the same looking website and app, is that people go back to saying, I will do it very custom made and designers become cool and design tools still have very much stay relevant and continue growing strong actually.

So that’s where we still think that the problem I mentioned earlier about design structure. It holds the key to a lot of the front-end automation around. And that is one of the toughest problems to solve. Because, uh, design structure, there are some patterns that can be automated. But even if you automate 80% and the remaining 20% doesn’t work, for the user to even identify which part of my design is in that 20% that didn’t work is one of the problems we are working on right now.

And we think once we can get there, design-to-code can become a lot more mainstream, because of the dependency. And I think especially with this notion of like, why should I do the work as a designer if the engineer benefits from it? If we can get the designers’ existing designs as they are without any requirements for them to go and manually restructure it, to then go and restructure it with an automation and then, you know, design to code works really well, that I think will be the toughest problem in the industry. And I think for, definitely, for what we stand for.

[00:50:59] The Future of Design & Engineering

Henry Suryawirawan: Yeah. Since you brought it up, I think it’s also a good point to discuss about it, right? Because in the industry, with the introduction of AI, almost every engineers are kinda like concerned about their role, right? In this case, for your particular use cases like designers and front-end engineers, right? So now I would imagine designers have the ability to produce code in some sense, and maybe can tweak it along the way. And for front-end engineers, um, you know, they have design capability as well, right? But obviously some people are concerned, you know, like, oh, does it mean we have lesser need for designers and front-end engineer? What do you think about, you know, the future of development, engineering, you know?

Honey Mittal: Yeah. And this is a topic I’m very, very passionate about as well. My co-founder and I did a talk at Figma Config called the Rise of the Design Engineer just, 3, 3, 4 months ago. So I do believe that, uh, there are gonna be changes, and they, I mean, they, changes are already kind of happening live, right? Still some, uh, I’m not still 100% convinced on some of these, uh, claims made that no more designers are needed, and then designers can do front-end engineering. But I do generally agree with the notion that designers can do the front-end development, and they have absolutely every reason and all the tools available today to do it.

The reason is simply because if you look at a designer, they do the designs and then they gave it to engineers. And then traditionally, two months, three months later, the engineer would come back and say, hey, I’ve built it, send it back to the designer. And then the designer goes, this is nowhere close to what I design. And then that back and forth between designers and engineers to essentially produce the same thing. But for the designer, what it means is frustration that I, this is was my vision of what I wanted to design, and then I have to keep talking to this engineer and try to get it to work that way. And they want ownership. So when we’ve talked to designers, we’ve said, look, if you, for the designers who are using Locofy, at least this is what they tell us, that I’m not a expert at front-end but I understand front-end techniques enough. And secondly, I use it because I get that code and I can make sure that that code when it runs on the user side is actually showing exactly the design I design through code. Whereas earlier, I had to kinda rely on the engineer.

So I think, yeah, that’s why we think that the designer’s role will evolve and should evolve. Also for the other reason that if you look at the last 15 years or so, engineering salaries have tripled, quadrupled because there’s a shortage of developers. Designers, on the other hand, I think there’s enough supply of designers. I have never heard of a company dying because, hey, I never found a designer, right? There obviously, there’s a spectrum, right? Really good designers are still difficult, but you can find designers with a lot more ease. And that’s why designers salaries have not grown anywhere compared to engineers in the last decade.

And now with design automation coming up, I think designers feel even more like squeezed from both sides. That a) there’s a lot of designers and how come I’m not getting a seat at the table? My salaries are not rising. And the second thing is now, oh, whoa, hold on. The role of a design intern can now be done by, you know, like Figma and Stitch, for example. There’s so many tools. UIzard, as it’s called. So I think for designers, it’s almost, I think, inevitable that they will end up owning more partly because of the need for them to kind of own the front-end, and partly because they themselves realize that, you know, I need to be doing more. I need to be having more impact. And today I have the tools, so why not?

But of course, it’ll still require them to have, like learn some front-end expertise because no AI is magic where it works until it works. But when it breaks, you need to know where it broke and even realize how to fix it after that. So that’s where I’ve been urging at least the designers in my team to start learning front-end concepts. Not be like front-end gurus, but at least understand concepts enough that if they’re using a tool, they don’t feel scared. They can own it and they can actually, they don’t have to keep going to engineers to keep asking for help.

So I think from design engineering point of view, I feel there’s already a revolution. But it doesn’t mean that, you know, the really experienced, high functioning, you know, designers who build complex systems should worry about this automation, because this automation is just producing. Like in Japan, there’s a term called Wabi-sabi, right? Which is, look, if everyone in your neighborhood, everyone, all your friends have the same table from IKEA, then you kind of want to make something custom made, right? And I think that’s essentially what’s going to happen with a lot of these design automations that real designers and advanced design tools will still be very much hot and in demand.

On the engineering side, I do feel that there’s been always been full-stack engineers. But I think there was a time when having just front-end engineers and back-end engineers made sense. I do think the lines will blur a little bit over there. So I don’t think of it as like jobs will go away, but team sizes and roles and responsibilities I think will merge a little bit. I mean, Figma did it to a large extent, if you think about it. Product managers and designers started designing together, and they brought them kind of close to each other. What we are doing can bring designers and front-end engineers very close to each other. And what Cursor kind of does, allows front-end engineers to do more full stack. So it’s less of replacing people and more of like giving them the opportunity to make themselves more full stack. That’s I think something, yeah, it’s inevitable.

And product managers as well, not just writing specs. You can solve your problems, do the analysis, create the first mockup, even if it’s done using LLM and everyone gets the same result, it’s enough to get an approval, for example. Then design it again from scratch, right? So where versus earlier, a product manager would go to a lead UX researcher to go do a research, a business PM to write the business use case, then a designer to do the design, and that would just slow them down. Today, I think any product manager should absolutely be 100% into AI and rather than having 10 in the team, you can have probably two or three. So yeah, I think roles will transform, but I don’t think it’s gonna be as crazy as it sounds that proper jobs will just completely be wiped out.

Henry Suryawirawan: I think one key message I would say that there will be more blending of skillset, right? So most likely, the adjacent thing, right? So designer and front-end engineer, maybe front-end engineer with design and backend, right? So definitely people need to upskill themselves and play around with these tools, right? So I like the term design engineer you mentioned. Maybe one day we’ll start seeing more roles design engineer, right?

Honey Mittal: My team has two designers. When the growth team basically wants to create some pages for SEO, AIO, for whatever, right? Now, the designers take that design, use Locofy, get the code, pull it into Cursor, just prompt, explain, and then publish it. And maybe an engineer needs 10 minutes to just review. So we are already freeing up the engineer’s time from slightly lower value tasks so they can focus on the core problems itself. And we are now starting to say we don’t have a product manager, for example. Our solution architects are the product managers. They can write. I mean, writing a PRD, I’ve never considered as product management. But they’re talking to customers. Why should there then be a product manager? The more number of people you add, the more the complexity, right? So our solution architects who help customers with their training and workshops can also come back and work directly with our designers and engineers.

So I think, yeah, these unnecessary roles that have been created during the height of the pandemic, I think, yeah, will go back. No more Business PM, Technical PM, Lead UX researcher, UI designer, UX designer, could just be a product manager and a designer. So I think that’s where things will be just more efficient and faster. Yeah.

[00:58:35] The Future of AI-Assisted Development Tools

Henry Suryawirawan: Yeah. So I think it was also brought up in one of my conversations before, right? So we used to have specializations simply because, like almost every part of the software engineering is like very complex, right? So if you think about it, right? So front-end itself, you know, you have so many frameworks, you have to understand maybe JavaScript, TypeScript, whatever that is. You have to understand the tools, the ecosystem and all that. It becomes like very complex and you need specialized skills. And now with maybe the help of AI, right? So the specialization becomes blurry and it’s turning into more generalization. This is where the trend is going as well, I believe.

And, uh, I would say that people need to be able to play around with these tools, which is my next question. With so many proliferation of tools, you know, you have maybe low-code, no-code, uh, you have AI driven tools, right? Well, what’s the future of this? Actually, I’m sometimes very confused, like where should we invest our effort and time?

Honey Mittal: Yeah. I don’t like to make bold predictions as if I know what’s gonna happen. Two years ago, we, I wouldn’t have predicted tool like Cursor, for example. I do think that engineering will become a lot more about some generalists who can do the work to get to a decision, to get to a point where, I mean, in large organizations, uh, it’s not just that engineering is complex, it’s also about getting people aligned on something. So I think over there, I think the hundreds of tools that require, and like generalists can go in and absolutely should. But I think it’ll be a combination of some sort of like a ChatGPT for research, for example. There are many tools out there obviously that can do that. Something like a Miro, Figma, Lovable, Bolt to do the initial sort of converting ideas into some sort of visuals because people tend to, you know, when you talk, like six people talk about a homepage, you’re all imagining different things. But a design essentially gets everyone to be looking at the same thing and align and make decisions. Beyond that, I think with a design tool that can help bring design and front-end together makes a ton of sense.

And I think obviously like a Cursor, Windsurf, Copilot for example, right? May not necessarily be your solution to everything. But things like code reviews, I think writing the logic with auto-suggest for certain things that you’ve designed already, that’s where I think the Cursors and the Windsurfs of the world obviously makes a lot of sense.

I’m not very familiar with the back-end side of things. I obviously am a front-end guy. Essentially what I’m trying to say is that there will be certain tools that will transform how you’ve done things in the past. I don’t think there will be one tool to rule them all. It’ll be a combination depending on your use case. So in the enterprise side, if you are a part of an innovation team, and you’re just producing things very quickly, use a Lovable or Bolt, for example. But if you’re building a production grade app, that may not be your answer. It could be a combination of a, like a Locofy plus Cursor. So the same organization might end up having a stack of tools rather than just invest into one and say, it’ll solve all your problems. And I think eventually, a couple of winners will emerge and they will start either merging, acquiring, or getting into these spaces.

But I think to think that one platform to rule it all or just one tool today that works today will be the tool you use in 10 years from now, no one knows, right? You try Cursor today and then Windsurf gets better tomorrow. And then one LLM doesn’t work today, and then all of a sudden Claude comes out and works well, and people say ChatGPT, Open, you know, the OpenAI models are not working well. But then we try the actual models and it works. No one knows what the real answers are. But I think the key is experimentation and the key is also giving the tools you’ve chosen a little bit more time, because it always starts with initial excitement, initially looks really good, then a learning curve. And that’s when you realize, oh, it’s not what I thought it would be because I have to do a certain amount of things and there’s a learning curve over there. So I would just say like I advise people against every month trying five, six new tools. But yeah, do your research, find a couple of tools that work for you. Define the grunt work that either your team doesn’t like or you don’t have the right people for. Start with that and then eventually start like kind of growing.

[01:02:53] There is No AI Moat

Henry Suryawirawan: Yeah. From my experience as well, like what you mentioned, right? So with so many different tools, different models, different whatever, right? So I think the key thing is obviously experimenting and know when to switch, right? Like sometimes like you can bang over your head with the same tools, but actually it doesn’t actually solve the problems. Now you have a plethora of tools that you can choose. And I find that as long as you still rely on these so-called popular foundational models, actually any tools you can use, you can just switch, right? There’s no moat per se, right? Maybe…

Honey Mittal: Especially with large language models, that’s exactly what it is. I think, uh, we’ve seen it every two months when I meet the team. Oh yeah, we ditched that one. Sonnet is doing better now. Like what happened? No, we are not using that. Llama is doing better now. So it keeps on changing. It’s hard to predict, but what’s constant is that they will play a big role. Which LLM, it would be a combination of two or three maybe. I don’t know. People will start realizing that when it comes to code, maybe Claude is better. When it comes to, I don’t know, research and product manager work, maybe ChatGPT and OpenAI models are better. And I think eventually people will just like stop experimenting too much and just trust that even if at a certain one of your chosen models is lagging behind, three or four months later, it’ll catch up eventually.

So yeah, but hard to say, man. Even for founders like me building an AI developer tool, it’s very hard to say where this is going to be, because there’s so much hype right now. So much hype, so much of initial trying and POCs and below in the next, I would say 12 to 18 months hopefully. But I do think that we are at the stage where in the next 12 to 18 months, a lot of startups are gonna die. And then the winners will emerge and then people can focus on those two or three.

[01:04:37] The Potential of SEA Talentsx Solving Global Problems

Henry Suryawirawan: So thanks for sharing all that, right? So I think one particular thing that I wanna pick from this conversation as well, because you are kind of like unique, right? You are building an application developer tools, right, from Southeast Asia for global markets. And I know this is one of your passion, right? Building, I dunno, global solutions from Southeast Asia region. So tell us about, you know, first of all, right, the promise of Southeast Asia region. Like do you see the skillset here is capable enough to actually solve global problems? And what do you see the trend so far?

Honey Mittal: Yeah. I mean, I’m super passionate, because I’ve been here 20 years. And yeah, I kind of decided I like to stay in Singapore and kind of make that chance that the Singapore maybe government took on me through a scholarship. Make it worth it. There’ve been enough times in my career where I’ve heard from people that Southeast Asia does not have the talent. And I understand where it comes from. But how does talent actually started? I mean, India didn’t have the engineering talent to build SaaS until Zoho built it against all the odds, and then now it’s becoming a SaaS factory. And I always believed that Southeast Asia needs the same. We don’t have a lack of talent. We do have a lack of taking big bets, I would say. And then the more I start understanding how the whole value chain works, it really comes down to risk capital, basically. The appetite for high risk moonshot projects, investing heavy amounts of money into it. In the West, we just don’t have it over here.

So I think over here, as much as I believe in Southeast Asia being, uh, you know, competitive and we have talent from around the world and stable government and like, founder-friendly, I would say, terms through capital gain tax and everything, just easy to do business. It’s still, I would say, not where the hype machine is. Um, but we do plan to or at least hope to change that. And there are companies like Supabase, LottieFiles that have origins over here. And there are ways of kind of being across two markets. So have your team in the US and Singapore, and get access to the best of both worlds. But yeah, I mean, I think Southeast Asia has the ingredients. I think in the last two to three years, obviously the risk capital has dropped tremendously. That doesn’t help any founders like us who want to change that from this part of the world.

But yeah. I would say I’m quite positive about the future, just how quickly it’ll happen and the role we can play into it remains to be seen. I do think we need, uh, when it comes to investments, which any startup needs, I still think for building a developer tool or an AI company, you just have to go to the West. And that’s been a realization lately that there’s no point debating and no point, like talking about what is the idealistic case? The reality is investors in this part of the world don’t have the same maybe risk appetite or the background of the history. Otherwise, Figma would be built from here. OpenAI would be built from here. I don’t think it’s necessarily because of the talent. Because we’ve had Singapore talent go to Silicon Valley and do well. And Silicon Valley also attracts talent. I mean, some of the best companies are being built by foreigners, but they go over there because they know there’s an opportunity. Not just that you get smarter by just being over there. We have enough talent over here. We just need the right sort of balance in the ecosystem. And I think it’s a work in progress.

Henry Suryawirawan: Yeah. I think, not to mention as well, when you mentioned about risk kind of like averse thing, right? So individuals themselves also probably take less bet. Uh, you know, that we want like a more stable jobs, you know, proper career and all that. So I think that mindset from individuals as well I think might need to change.

[01:08:14] The Challenges Building Dev Tools in SEA

Henry Suryawirawan: So you mentioned about building dev tools kind of like difficult here. I know that we have many startups here that are turning into big as well, but yeah, they’re solving more like, I dunno, like society problem, maybe business problems and all that. Why particularly building dev tools is not popular here? Is it like, I dunno, some trends or some mindset because we have talents, we have developers here building solutions.

Honey Mittal: I think Southeast Asia startup scene is now kind of going into the second wave, right? The first wave is generally communication, e-commerce, logistics, right? FinTech. It’s just been a decade actually, not more than that. And I think now we have enough experienced engineering leaders and startup builders and operators who go and say, yeah, you know what, it’s, it was fun building Lazada, fun building Grab. And we learned a lot. But the real geeks will say, I wanna go deeper. What seemed impossible almost five years ago, building an app that, you know, you can show location on and like connect Stripe to it, today doesn’t excite me anymore. I wanna go deeper into either front-end, back-end, or anything. Anything that people are passionate about.

I think 10 years ago, we just didn’t have enough examples around us, enough investors, and enough, I think, experience in the operator side to go that deep into deep tech. I think that’s changing now, which is why we have, I think, in the last five years I’ve seen maybe seven or eight developer tool companies come from this part of the world and eventually decided to move to Silicon Valley. Because people, you will have a reminder on a daily basis, why are you over here? Why are you building from Singapore? Just go where all the developers are. Because one thing true about Silicon Valley is that the amount of early adopters and people who are willing to try something that’s not yet perfect, the density in Silicon Valley is just insanely high on the addition of obviously the risk capital that I talked about earlier.

And I think that’s why in Southeast Asia, it’s difficult because I think the early adopters may exist, but it’s a very, very small number. Like Indonesia, Southeast Asia, they generally tend to follow what’s coming from the West. I don’t think it’s something that cannot change and will not change. It will. But we just need maybe three or four strong examples built from this part of the world to both attract more founders to solve these kind of problems, global problems, and not just Southeast Asia problems. More deep, deep tech problems than just on the application there. And also will attract the right investors after we have some exits, I would say.

[01:10:39] The Challenges Being a Fully Remote Company in SEA

Henry Suryawirawan: Yeah. So I think one example is definitely Locofy.ai, right? Yeah. And, and I know that you are interestingly a remote company, right? Fully remote company and you have developers across different countries. So tell us, I think one problem for Southeast Asia is like how fragmented, you know, the region are, right? So many different countries, different culture, different language, you know, different norms, whatever that is, right? Different even like lifestyle and, you know, rate of living, right? So tell us like what’s, uh, the challenge here when you built fully remote company from Southeast Asia?

Honey Mittal: Yeah. So I think nature of the problem was such that we thought we don’t necessarily have to be in the office, right? Like because of COVID, I guess designers and engineers and product managers became very comfortable working with each other. As long as you have the right people you can trust. The bigger challenge was still that the early adopters of our product are still very much like around the world and not just in Southeast Asia. So today, we are building from Singapore, but less than 5% of our revenue is from this part of the world. We were solving a global problem from day one, and we wanted to build from this part of the world because there’s a lot of benefits. Like I’ve said, easy to start a company and we had background over here. Our first 10, 15 people we knew we wanted to work with were over here. But yeah, as the company matures a little bit and we start going into GTM, start going into fundraising, the challenge can be not just being remote, but being in this part of the world.

And secondly, now we have people from all around the world. And if majority of the customers are going to be in the west, time zones can become a bit of a problem. Culturally, I think it, it’s a little bit difficult to manage maybe more than 30 people remote than with 10 people. 10 people remote, we hung out every day. 30 people, sometimes we see people and I’m like other than making them an offer, I don’t remember talking to them. So the challenges will always be that, look, problems get solved much faster when you sit together, have a whiteboard, or sometimes you, online will take you five days, six days to get people to really get going versus in person is just better that way. Selling to customers is generally better in person.

But what works remotely very well is that our engineers are not spending any time in traffic. They’re not living in expensive CBD areas to be closer to office. Not just in Singapore, but in the six, seven markets we have our team members in and they get the time to do more important things in life, right? Like there’s no reason why you have to work 12 hours a day and, uh, miss out, like your kid goes to school and you don’t get to see them at night, for example, right? And sometimes you just wanna take a nap, a 15-minute nap and you get a productivity, you know, like boost all of a sudden. Those kind of things, I think is very, very hard to get in an office environment. And we’ve seen that people in our team appreciate that they can stay home. They’re working hard as hell, but they don’t miss out the important things in life, whether they’re parents, whether it’s taking care of their family, even walking their dog, for example, taking care of their health sometimes.

I think, yeah, we are still very much going to try and keep it remote as long as possible. But I was say, as I was saying to you earlier, I’ve started now feeling and some other people in the team have started saying as well that sometimes we just wish we were sitting in an office in a, to solve this tougher problem. Sit in one room for a full day, we would’ve found a solution whereas online can be a bit challenging that way. And also you have good days and bad days. And when you have bad days, it’s easy to have a colleague who you can go down for a coffee with, went out and move on versus being remote. I think sometimes you, no one even knows you’re going through something.

So I think, yeah, it has its pros and cons, but it allows us to hire in every part of the world, which is a huge pro. And engineers and designers like the fact that they can be just in front of a laptop and not like spend two hours in the morning getting ready, getting to work, and then back. They would rather spend those three, four hours a day doing other things outside of work and still get the productivity boost they need. Yeah.

[01:14:36] Locofy Traction and ARR

Henry Suryawirawan: Right. You, you mentioned that, um, interestingly, your customers starting to get, you know, like you get it from, not from this region, right? So tell us a little bit about the traction of Locofy so far. You, you know, you have been around four and a half years. What’s the stage like? You know, how much customers base, how much revenue you…?

Honey Mittal: Yeah. So we were in free beta for three and a half years. And that helped us, uh, and I mean, we didn’t really, we did really well on Product Hunt and Indie Hackers, Twitter. Like YouTube, people just kept making videos about us when they found out about us. TikTok went viral at one point. So we were lucky that we built a strong beta community rather. And when we monetized eventually last year, we had signs that enterprises and full stack engineers were actually where the strong product market fit like. So we started charging our customers exactly a year ago. The first quarter, we started realizing the pricing was a little bit off here and there, and workshops were important, and we need to have a sales person in the sales deck and everything. It takes time. It’s only earlier this year we realized that we’ve gotten the pricing right. Like not a seat-based model, but a usage-based model. And also pricing that doesn’t push enterprises towards self service where they, we know they will struggle because there’s no training available.

But yeah, after we figured it out, it took us, uh, nine months to get to our first million revenue, and now we are at a one year stage. We are, just crossed 1.5. Our customers are mainly actually, we’ve seen a strong product-market fit with system integrators and agencies. Maybe because of the skill gap over there, maybe because of their own business model itself, it makes sense for them to be able to build faster and cheaper. And when it comes to the kind of enterprises other than system integrators and agencies, think of like companies like Toyota, Bupa, for example. Insurance companies, banks, security bank, DBS, all these kind of large enterprises that have ambitions to be a tech company. But they don’t necessarily attract the best software engineers. So Toyota attracts really good mechanical engineers and automobile engineers. But would the best Stanford, you know, software engineer, prefer to go to a Facebook or to Toyota, right? Doesn’t mean that Toyota and the Bupa of the world don’t have ambitions too and they don’t have the budgets too. But that’s where we’ve seen strong product-market fit, where they haven’t been able to attract, you know, the 10 out of 10 engineers maybe. But they’re really good at what they do and they have ambitions to be a tech company. So that’s where we’ve seen a strong product-market fit.

And when it comes to startups, we are working on a slightly simpler flow today to kind of circumvent the design optimization issues I mentioned to you earlier. And also to fit into the Cursors of the world a little bit better. More UI-less, for example, go from 15 steps to just one step, where you can take your Figma design, run Locofy design models with just a click, and then immediately continue into Cursor, for example, rather than adding more steps.

Henry Suryawirawan: Congratulations for such a rapid, you know, traction, revenue and all that. So for sure that I hope these tools will get more traction because I believe it solves a real problem, right? Especially, for builders, right? For people who would like to build products, especially the, you know, front-end web products, right?

So we have covered a lot of things, is there anything in particular that you think we missed or you want to also convey in this conversation?

Honey Mittal: Uh, not particularly. I would say. No, man. I think we’ve covered it, yeah.

[01:18:09] 3 Tech Lead Wisdom

Henry Suryawirawan: So, as we wrap up, uh, our conversation today, uh, Honey, I have one last question, uh, which is like a tradition in my podcast. I call this the three technical leadership wisdom. So think of it just like advice you want to give to the listeners. Maybe if you can share a version from you today, that be great.

Honey Mittal: I would say that I will share what I follow myself. Otherwise, what’s the point? I think number one is don’t get too comfortable ever, especially if you’re working in the tech industry. I think engineers, for a long time, they thought that they were invincible. And I think the last three, four years have been, I would say, humbling for a lot of us. Product managers, engineers, designers. So always stay nimble. Always keep learning. Like learning shouldn’t stop after university. And I think you should, no matter how long you’ve been in the company, 10 years, 15 years today, your role is never safe. That’s the reality. And if you keep working with that mentality that I will never get comfortable just because I’ve earned the right to be comfortable, I think you’ll be fine. Waves will come, innovations will come and go, hype cycles will come and go, but if you are… yeah, don’t box yourself to be just like I’m a PWA guy, or I’m a mobile app builder. Keep learning what’s coming, what’s new with technology. Don’t fall in obviously for all the hype, but keep reinventing yourself.

Like my co-founder, for example, went from being a gaming engineer to a mobile app engineer, to then a PWA engineer, and now an AI expert, pretty much. And he’s 40. Usually at this stage you’ll be like, I would be a line manager, I just manage some people and work on some tough problems. But I’m the Ruby on Rails guy, or I’m the back-end guy, or I’m the AWS expert. So I think it’s good to push yourself to become as close to being an expert as possible, but also don’t box yourself in just this feeling of I’ve earned it. I’ve worked so many years on something, I’m an expert and I’m safe now, and I can take it easy. That’s just one of the things.

So leadership and management are two different things. I believe in leadership, but not becoming like a line manager. I think 50% of the millions of people who’ve been fired in the last three, four years are actually those managers. So yeah, just always be an individual contributor and of course, learn how to manage and learn how to lead teams and lead tough problems. Yeah, put yourself in a position where you cannot be boxed into just one thing and like that whole function or that role goes away. That would be number one.

I would say, don’t be like, oh, you are a Chief Product Officer and now I can just go to next company and be a Chief Product Officer. I generally believe that we are living in a world where it’s very different from how our parents grew up. Like in their generation, it was believed they will live until 70, maybe. And it was divided into three phases, right? The first 25 years to learn. Next 25 years to earn by becoming an expert at something. And the next 25 years or 20 years to just retire based on what you earn. Now as life expectancy has obviously changed tremendously, and it will continue doing so, like to think you live until 90 or 100 is not considered crazy. And when that happens, whatever makes you an expert in your thirties will not be enough for you to continue until you’re 60, 70. So I think it’s important for people to start taking designated breaks, career breaks to go and reinvent themselves, to always be hands-on to what I just said. And to never feel like, but I’m not an AI expert.

When AI wave came, I didn’t study AI in university, but we got our hands dirty. And it, you’ll go through a period where you are uncomfortable, you feel lost, you feel like I’m just not young enough to learn. But you have to keep powering through because very quickly you’ll become that expert that everyone wants you to be. And I think it applies to leaders more importantly than others, because, yeah, you’re not just in a team or in an organization for the quality of decision and the experience you bring in, but also for seeing it through. And the execution piece should never become like, hey, the last time I did something like this was 10 years ago to stay relevant and to stay ahead of the curve as well. Yeah.

Be a problem solver. Technologies will come and go but yeah, if you’re too far away from the tech, then at some point of time organizations will prefer younger, hungrier, and more adaptable graduates. So I think it’s more that’s what mantra I follow. If that’s the only advice I would give, I’ll be happy with that as well, yeah.

Henry Suryawirawan: Yeah, I think that’s a very great reminder, especially for people who have been around for quite a number of years, right? So especially line managers or maybe leaders, right? So always gets your hand dirty, you know, being hands on. Especially now. Actually with AI tools, I feel as someone who have been around in the industry for quite some time, it’s actually a powerful leverage. You can learn so much things quickly. Yeah. And anything, anything you can learn, right? So you can actually pick it up and, you know, try it out and even write prototypes, code and all that. Because in the past, maybe the first hurdle is like the how. We don’t have the muscle to actually build something, you know, the know-how. But now I think AI can help us in the first step to actually build something and maybe iterate from there. So I think that’s a very great reminder.

So Honey, if people would love to connect with you, learn more from you, learn more about Locofy, is there place where they can find you online?

Honey Mittal: I’m on LinkedIn all the time. Other than that, I think, um, my email address should actually be available on the, on our website as well. But yeah, LinkedIn I would say would be the best place to find us or me. And then, uh, you can always book a call on our website where you book a demo or an exploration session with us. And more often than not, I’ll be on that call, yeah.

Henry Suryawirawan: Right. So again, thank you for sharing about Locofy today. I’m sure many engineers or designers who are hearing this conversation will be very excited, and I hope they try out your tools. And yeah, all the best for the journey.

Honey Mittal: Thanks for having me, man. This is a great conversation. I appreciate, appreciate you having me on the podcast as well. Yeah.

Henry Suryawirawan: Yeah.

– End –