My team has two designers. When the growth team wants to
create some pages, 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. Locofy converts your existing
Figma designs into whichever sort of front-end framework.
React, Angular, Vue, HTML, CSS, Flutter, React Native, pretty
much anything. Cut the time by 70-80%.
Honey Mittal built his own large design models before ChatGPT
existed. Spent four years on AI that
understands visual design, not just text.
His company, Locofy, now helps engineers build front-end 2 - 3
times faster. As we were launching this,
ChatGPT launched. And we started hearing this term
LLMs. But the more we looked at LLMs, the more we realized the
LLMs architecture itself makes it super hard, if not impossible
to understand Figma design. We spent about four years
building our design models from scratch.
We call it the large design models.
You mentioned about maybe 70%, 80% reduction.
How long does it take for you to generate?
The code itself? Not more than 20 to 30 seconds.
An engineer who was able to do 10 designs or 10 screens per
month is now able to do 25 to 30.
We have customers who have built large projects of 1,000+
screens. In a matter of months using
Locofy. And I do believe that designers
can do the front-end development and they have absolutely every
reason and all the tools available today to do it.
No more Business PM, Technical PM, Lead UX Researcher, UI
Designer, UX Designer. Could just be a Product Manager
and a Designer. 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. Thanks for having me, Henry.
Yeah. Good to see this happening in
Singapore. 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?
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.
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?
Yeah. 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? 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.
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.
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. 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.
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?
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.
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.
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?
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.
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.
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.
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? 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. Right.
Maybe a bit of trivia, I would assume Locofy here stands for
low-code-ify? Is that correct?
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.
I see. Okay.
I like that thinking process. 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? 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.
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?
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. 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?
The code itself? Yeah.
I mean, not more than 20 to 30 seconds.
Wow, okay. 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.
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? 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.
Wow. So thanks for sharing all this.
I dunno how much is proprietary, but I think we get a peek into
internal.. 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.
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?
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. 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. 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.
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. 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. 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. 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?
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. 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? 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.
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? 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.
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? 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. 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... 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. 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? 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. 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.
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.
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.
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? 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. 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...?
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.
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? Uh, not particularly.
I would say. No, man.
I think we've covered it, yeah. 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. 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.
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? 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. 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. Thanks for having me, man.
This is a great conversation. I appreciate, appreciate you
having me on the podcast as well.
Yeah. Yeah.