Figma files for proposed IPO
figma.com
figma.com
Their highlighted metrics page: $821M LTM revenue, 46% YoY revenue growth, 18% non-GAAP operating margin, 91% gross margin.
It's an incredible success story, and the engineering they did upfront (primarily led by co-founder Evan Wallace) that set the stage for their success is the stuff of legends. https://madebyevan.com/figma/ has links to numerous blog posts breaking it down, but here are some choice quotes:
> [Evan] developed the hybrid C++/JavaScript architecture for Figma's editor that made it possible to build a best-in-class design tool in the browser. The document representation and canvas area is in C++ while the UI around the canvas is in JavaScript (the team eventually settled on TypeScript + React for this). This let us heavily optimize the document representation to reduce memory usage and improve editing speed while still using modern UI technologies for fast iteration on our UI. C++ development was done using Xcode (not in the browser) to provide a better debugging environment.
> Even though the contents of Figma documents are similar to what HTML can display, Figma actually does all of its own document rendering for cross-browser consistency and performance. Figma uses WebGL for rendering which bypasses most of the browser's HTML rendering pipeline and lets the app work closely with the graphics card. The rendering engine handles curve rendering, images, blurs, masking, blending, and opacity groups, and optimizes for high visual fidelity.
> [Evan] developed Figma's multiplayer syncing protocol, worked on the initial version of the multiplayer live collaboration service (a kind of specialized real-time database), and added multiplayer syncing support to Figma's existing editing application. The initial version was written in TypeScript but [he] later ported it to Rust for improved performance and stability.
It's a great reminder that it's not premature optimization if your UI's fluidity is your distinctive feature and your calling card! And the business acumen to turn this into such a wildly successful product in the context of competitors with kitchen-sink feature lists can't be understated, either. I have an incredible amount of respect for this team, and they should inspire all of us to tackle ambitious projects.
The brilliance of the system he built was that it allowed for real time collaboration. Which was god send from the Sketch -> Zeplin -> Invision -> Avocode (version management) ‘stack’ that lost Enterprise design orgs were using.
Which was already a large leap from what Adobe was expecting us to do with Photoshop/Illustrator (after they depreciated Fireworks).
Figma made handoff much easier. Made version control dead simple. Made my life as a UX leader much much better. I remembered talking to a few now-Gigantic companies back then and we all plotted the move together
It wasn’t lost on us that Sketch is/was much much smoother with its usage of Mac OS’s native shape rendering. It’s just that the benefits far outweighed the small drop in snappiness.
And for anyone who’s going to say “Sketch was Mac only that’s why it failed!” I assure you that had nothing to do with it. For the same reasons an entire generation of UX/UI designers stopped using Axure. But we would need to start talking about Invision 7 and Invision Studio if you wanted to get into the nitty gritty.
> It wasn’t lost on us that Sketch is/was much much smoother with its usage of Mac OS’s native shape rendering. It’s just that the benefits far outweighed the small drop in snappiness.
I was at a SXSW session with XD's product team in the early weeks/months of that products existence. The Q&A section was filled with a lot of dismissive statements and questions. XD was never going to survive.
Why would anyone say that? Sketch is still alive and (presumably) well. Apple themselves continue to officially release design files for Sketch with every OS release. They share more resources for Sketch than any other app, including Figma and Photoshop.
http://developer.apple.com/design/resources/
> after they depreciated Fireworks
I’ve been seeing that word used a lot in this context, so just wanted to point out (I’d appreciate if someone did the same for me) that what you mean is “deprecated” (no “i”), as depreciating is a different thing.
When people deep into the startup-woods say "Fail" what they really mean is "Didn't take over the world". Their perspective of "winning / failing" is a bit more black and white than the average person.
With that said, Sketch certainly didn't become more popular because the macOS requirement even for viewing the files. I remember that there was some hacks to be able to at least view them on Linux, and other things like Zepplin (or similar) made it even easier, but it was still cumbersome.
Then Figma appeared, offered more or less the same features, slightly worse performance than Sketch, but worked absolutely everywhere and was easy to open and inspect things for everyone on the team. Obviously, Figma ate a lot of the Sketch user-base, which is something I saw in multiple companies myself.
Good point (also, “deep into the startup-woods” is a great way to put it). I suspect there’s a major overlap between those people and the ones who are obsessed with products “killing” another. The same kind of people who are hyped by any new shiny pebble as if it’s the second coming of Christ and immediately eschew everything which came before. The people who are so blind to context they shouted “zOMG Google is dead because of ChatGPT” because they were incapable of thinking for two seconds that Google has a ton of cash to survive in the long run, were already leading research in the field, and (of course) wouldn’t just fold their arms and stay still. In short, people not worth listening to.
Sketch dominated the landscape. Now they are a small percentage of the landscape. I characterized that as a 'fail'. Sure, maybe an inexact word but what else do you call going from 60%+ of the market share down to below 20%? And btw I currently pay Sketch $120 for a personal license (so they obviously haven't failed in that sense).
And spare me the 'context' thing. Because my context on this subject is as a individual contributor, leader of multiple large design orgs with dozens of designers all in the same tools, as an early Sketch, Figma, Invision and Framer X customer. The context is up there with the Console Wars but I don't have the room for that here.
What's your context?
Have a great day!
But if you felt attacked, that is entirely on you. It wasn’t at all my intention, and my comment is pretty clearly a continuation of what the other user said, which in my view also didn’t attack anyone specifically. Yours was one of the strangest and most unexpected responses I got in recent memory, and it took me a bit to even understand why you were so mad and thumping your chest. Hilarious and bewildering indeed.
Yes, Sketch's logo has been featured in a Apple keynote before. I'm familiar with their relationship with Apple and it seems like their team is perfectly happy not being the gargantuan that Figma is.
Sometimes I feel like people just want to find any reason to disagree on here.
Lastly, maybe you should just make a depreciation (sic) bot.
Writing this from the perspective of someone who used to spend all day every day in Photoshop/Sketch/Figma for decades. This markedly contradicts my recollection of the state of Sketch at the time Figma was in its first public beta. Sketch's performance was abhorrent and it was constantly crashing while working with libraries. I was very skeptical about web-technology based tool in terms of performance, but Figma blew me away. It was FAST.
Of course, the reality was that performance is a super nuanced thing. It's always measured in relation to specific things, but ultimately summarized via a "feeling".
Aspects of performance include:
- Loading a (blank/medium/large) file from (scratch/cache/etc)
- Performance when editing (what?), panning, zooming (small or large doc?)
- Performance with a large number of simple objects, or complex objects (components? variables? nested components? drop shadows/background blurs?)
I haven't personally done some performance comparisons between the two apps since ~2018 but at the time there were definitely things where Figma was noticeably faster than sketch, a lot of things that were comparable, some things that were slower. My own very biased feeling was that Figma was faster more often than not but it's always up to the individual use case, how their file is setup, what they are doing within that file, and how they mentally weigh those different scenarios.
I definitely didn't feel like being on the web was a limiting factor. In some theoretical state, with infinite resources to optimize everything, native could be faster since you have access to lower-level APIs. In practice, that's the same argument as "it could be faster in hand-written assembly". Almost never did we get to the point where we'd use those abilities even if we had them, due to their cost on development and impact on the correctness/maintainability of the code.
Figma just has to jack up the price in order to appease Wall Street quarterly.
Business wise it's got a great margin, but the avaricious nature of Wall St. will force them to enshittify the entire product, the engineering doesn't matter unless Wall St. is satisfied.
Aren't designers mad at Adobe for doing exactly this?
There are several things designers need that Figma has dragged their feet on for years, and when they do release them, they’re usually behind the enterprise paywall. Or they don’t release them at all, instead opting to build some horizontal product like Slides because their investors want a bigger TAM.
Figma has the power of the network effect at present, but you can only charge people to use variables for so long before they look for an alternative.
- Can't set connectors on Design files (used for documenting the navigation flow between different pages of an app).
- You can set connectors on FigJam files, but if you want to bring your components from Design files then you can't keep the instances synchronised to the component definition. And you can't attach the connector endpoint to some element inside the Design component. It's essentially just an image export of the Design component.
- Prototyping is very clunky and trying to build a flow that has elements reacting to interactions on other distinct elements is either variable hell or downright impossible.
Those are just off the top of my mind. I'm always finding threads from 5 years ago on their community forums with loads of people on the same boat and no activity from Figma side.
- Poor typography support: can't embed fonts in files, can't tweak type enough (can't do faux italics for example)
- Subpar file/project management: can't do things like nested folders which gets overwhelming with large projects/teams
- Clunky version control: browsing long file histories is inefficient, the entire VCS UI is forced into a narrow sidebar
Also just off the top of my mind. There's also lots more if you're coming from a print design world and are thus used to Adobe Illustrator.
Ah, there's another one you just reminded me:
- Poor paragraph justification algorithm; there's no hyphenation system.
This one is table stakes for professional print design.
Great. What's the point of achieving great things with hard work if one is still stuck working with same product for life.
> I have a hard time being interested in something that has such a painful..
Thats okay. One can always use products that are reasonable to their expense budget. Not every product is to be used by every one.
And thats how you get designers whining that their design looks great in figma but not in a real webpage
I’ve been thinking about a box-first approach to design tooling. The overall layout workflow would consist only of adding boxes (block-level elements) to a blank web page, or inside other boxes. Boxes could also contain other elements like inputs, buttons, images, etc.
More like ”no-code design directly in HTML and CSS”, but with familiar Figma/Sketch-line controls for sizing, alignment, etc. Responsive by default, boxes full-width and vertically sized by content by default, manual pixel sizing of elements heavily discouraged in favor of block/inline-block/inline. Sane defaults for theme tokens, but easily customizable.
In other words, a hands-on design tool for web layouts, working directly on the DOM and stylesheet, preferring the flow for positioning and leveraging (normalized) HTML/CSS defaults.
My thinking is mostly born out of frustration with the performance of flexbox-inside-flexbox layouts and the total disparity of text layout between web and existing design tools.
Is the book that good?
This thread started about "boxes", I probably should've linked directly to this page: https://every-layout.dev/rudiments/boxes/
I work on a large web based application, with designers, who use Figma. It's just too easy to lose the plot and come up with things that don't work well. Not because of Figma. Something about the balance between the software stack(s), the domain, the focus of designers today, the front end engineering, and product management is broken. It's interesting that Figma did (IMO) a great job at addressing the stack so they can build a product that does what they want it and then is used by so many to build products that don't always do what their customers want. Asking Figma to use the wrong stack for their product (which is what I'm reading between the lines) is not really the right answer...
I'll call Google and I'm sure they'll get right on aligning their browser's rendering engine with figma's
What about other browsers? Versions? Platforms? OS? Resolution/screen size? My huge frontend team can't handle this, even before we used Figma.
Isn't the problem trying to get this "web platform" do something it was never meant to do? How would this be solved by Figma using a rendering engine that would grind their product to a halt?
I'm old enough to have done a lot of native platform UI work, the web stack in many ways was a step backwards. It has obviously a lot of advantages (run anywhere) but in some ways it's more like IBM terminals on a mainframe vs. a native UI where you have full control. I (obviously) use and make web apps all the time, but they often suck, and this isn't Figma's fault.
I'm sure there's something fundamentally wrong with the font files. In both cases, they're not standard, widely available fonts. With that said, browsers render the fonts consistently with each other, but not Figma.
There's also a lot of ways that figma can lead designers down the unhappy path. They'll put together two different screens that look great, wave their hands around the idea of "just make it responsive" and when you go in and look, there's nonsensical crap like absolute positioning on elements, or arrangements that don't work with block layouts and force you into convoluted grid stuff.
Figma is clearly built to be useful for web development. It has tons of gaps that lead designers off the happy path. Take out all the "browsers / versions / os / screen size" differences from the argument; my points above would apply to any design tool built for any product. If it doesn't accurately reflect what is possible or how something is done, it's not a perfect fit.
PS: I prefer figma over pretty much every other tool I've used. With that said, there's no pretending that it is perfect, nor any reason to deflect accurate criticism elsewhere.
Not because they can't be leaders in the space, but because there won't be any moat.
One example of that is something like he adapted a shader we use internally to render font glyphs, which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.
Any code that involves parsing old school binary file formats is going to look ugly to modern day developers who are used to JSON everything, even if the code is actually very well structured.
But there are plenty of Hard Problems out there, for which no sufficient code could be called “simple.” Plenty of aspects of font rendering fall within this bucket. It’s notoriously difficult.
It’s inherently (and likely irreducibly) difficult, not accidentally/gratuitously difficult.
Usually when I see some mathematical code that's not explained at all and has obvious flaws in terms of simple improvements that could be made to improve readability or even something as simple as some comments, I just keep thinking: "Please don't let this person touch application level code!"
The hard part is knowing when the code is complex because the domain/performance requirements demand it be that way vs when the code is complex because the engineer was just trying to appear smarter than they are.
yikes
I wouldn't glorify "brilliant code" that much though because code should be made to be changed. If it isn't, it's a fragility trait, not a positive trait. Code that no one knows how to change is opportunity lost.
I do understand that it may be hard to create stuff for others when you're alone and going very fast but I don't think praising it is the right idea.
Code that doesn't need to change is a really good sign that you've got something good.
> Code that doesn't need to change is a really good sign that you've got something good.
Not really, but you're thinking in terms of "my code nailed it because I'm not touching it" and that has NOTHING to do with it being easy to change.
I worked extensively in the parts of the Figma where Evan wrote a lot of foundational code, and have also worked directly with him on building the plugin API.
One of Evan's strong points as a CTO is that he was very pragmatic and that was reflected in his code. Things that could be simple were simple, things that needed complexity did not shy away from it.
While all codebases have early decisions that later get changed, I'd say that largely speaking, Figma's editor codebase was built upon foundations that stood the test of time. This includes choices such as the APIs used to build product code, interact with multiplayer, the balance between using OOP v.s. more functional or JS-like patterns, the balance between writing code in C++/WASM v.s. JS, etc. Many of these choices can be credited to Evan directly or his influence.
Subsequent engineers that joined were able to build upon the product without causing a spiraling mess of complexity thanks to those good decisions made early on. In my opinion, this is why Figma was able to ship complex new features without being bogged down by exploding tech debt, and a major contributing factor to the business's success as a whole.
I think that Evan generally wrote code that was as simple as possible — there was no unnecessary complexity. In this case there indeed is some inherent, unavoidable complexity due to the math involved and the performance requirements, but otherwise I found our text rendering pipeline very understandable.
Evan actually wrote about it if you're curious to learn more: https://medium.com/@evanwallace/easy-scalable-text-rendering...
[0]: https://www.figma.com/blog/introducing-vector-networks/
Every now and then I'm writing a PoC or greenfield project that you put down for 6 months. And sometimes when I pick it up to extend it, it will just so rapidly feel like it's getting out of control (I'm actually listening to the chemical brothers song of the same name at the moment!). I can at least usually fix that with some refactoring, but why didn't I get it right at the time? I don't know.
And it's often hard to figure out why, what architectural decision did you make to cause this. Pointing at the particular interface or pattern or method call chain that is the cause of a ton of complexity that could be fixed is much, much, much harder than most jobs in programming. And beyond the ability of 90% of developers.
The -2000 story popped up here again recently (https://news.ycombinator.com/item?id=44381252), and it's of the same vein, why had no-one else done that? Because it takes extreme skill to simplify existing code. It's beyond most developers.
I think it's why we as an industry often obsess about things like space/tabs/semi-colons or not/etc. They're obvious improvements to an architecture, and everyone can join in. But really, they're a small improvement to a codebase, not a massive one.
And then you get the Evans of the world who just do it, almost effortlessly. I've worked with an Evan, and sometimes you'd look at his code and think "why?", but any attempt to change or improve it invariably made it worse. He'd picked that pattern or structure or method call chain and it was always the right choice. And after a day of poking at it, exploring the edges, trying to change it, you'd realize why.
And yes, sometimes the code was so complex other developers couldn't get it. And then they'd call me over to help because I could get it. And I'd look at it and realize it was complicated because it had to be like that. He'd actually done it in the simplest way possible.
And years later I still make the wrong choice sometimes, and I always think of Simon and wish I had his magic touch.
Even if he used to name functions Thing() and DoStuff() and forget to update them.
I cannot believe Figma hired engineers who could not follow along already-tread footsteps. That’s a nonsensical assertion. Novel code may be inscrutable but the problem-solving and techniques should have been clear and repeatable by those who follow, even if they require adaptation.
How the legends have fallen
[1] https://github.com/evanw/esbuild [2] https://github.com/microsoft/typescript-go
> Our vision for the future of design tools is one where both the tool and the content are easily available to anyone, anywhere
> The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
> We fully control memory layout and can use compact 32-bit floats or even bytes when appropriate instead of JavaScript’s 64-bit doubles...The generated code is completely in control of allocation, which makes it much easier to hit 60fps by avoiding GC pauses. All C++ objects are just reserved ranges in a pre-allocated typed array so the JavaScript GC is never involved.
> One big issue for us was that certain browser configurations couldn’t allocate large ranges of continuous address space for the huge typed array that contains the entire emscripten memory space. The worst case was 32-bit Chrome on Windows which sometimes couldn’t even allocate a 256mb typed array because ASLR was fragmenting the address space. This has since been fixed.
A great example of making a single bold architectural decision (building a design tool on the web instead of as an app) in service of a vision (prioritize live collaboration), and then thoughtfully resolving all of the performance tradeoffs that stem from this route.
None of this "designed for newspaper print" style layout. Yes, I know flexbox is very good. But it's still a hack (imo).
"Immediately following the completion of this offering, and assuming no exercise of the underwriters’ over-allotment option, Dylan Field, our Chair of our Board of Directors, Chief Executive Officer, and President will hold or have the ability to control approximately % of the voting power of our outstanding capital stock, including % of the voting power pursuant to the Wallace Proxy. As a result, following this offering, Mr. Field will have the ability to control the outcome of matters submitted to our stockholders for approval, including the election of our directors and the approval of any change of control transaction."
It does, however, hurt the Wall Street investors. If they have enough power to do so, they will replace the CEO if a share price is too low for too long.
That’s what creates the short term incentive that is a trouble and a lot of public companies. If the CEO has control of the voting shares, that pressure is relieved.
There's a good reason public shareholders historically demanded accountability - maybe it's fine for now, but all it takes is some management that you can't kick out, paying themselves extortionate salaries and driving the company into the ground at the same time to recognise the problems with "owning" a company you have no right to actually control (via replacing management and so on)
A board of directors can screw shareholders even without one controlling director.
The protections for minority shareholder are seperate.
Also the news of malpractice by directors like you mention leads to SEC investigations and stocks come crashing down before they can sell it (as they must declare their stock sales a few days before doing it)
It's going to be a lot harder to protect your rights, especially around the margins, if you agree to terms like the above.
It makes sense, you're disposing of the capital the shareholders own.
Dodge v. Ford Motor Co. was a civil case, not a criminal case. And it was in the Michigan Supreme Court so has no standing in the other 49 states.
And in practice the "business judgement rule" makes it very easy for businesses to do whatever they want as long as they have a vaguely plausible explanation for how it helps the business as a whole. ("We need to buy a private jet for our CEO because he is integral to our growth and success.")
The most efficient government is a benevolent dictatorship, the problem, of course is that benevolent dictators don’t live forever and sooner or later you get a non-benevolent one.
These sorts of dual class share structures avoid that issue by generally becoming common stock on transfer so it turns into a democracy with the end of the dictator.
With an IPO you at least got to spend several years seeing how the dictator did.
$300k/DAY AWS bill. I wonder what the "non-cancellable" savings is.
Multiplayer means that every file that are user loads is loaded onto a compute server and retained in-memory on that server, processing every mutation to the document. Figma documents can get quite large -- they can contain the design system of an entire organization, dozens of variations of a product feature, etc. This means the server cost scales per active session at a given time, a higher "number" than active requests.
In addition to multiplayer, Figma attempts to keep most other parts of the application real-time. If another user adds a file to a project, you will see it without refreshing the page. That's a simple example, but certain types of queries/mutation can get much more complex.
Figma is an enterprise app, and the data models needed to support complex use cases (permissions, etc) means that DB load is a real challenge.
While the DAU count of Figma might not be as high as other consumer apps, the amount of time those users spend in Figma is often substantially higher.
Those are some of the things that contribute to a high bill. While Figma is most known for the frontend editor, the infra work is plenty interesting too.
This, “permissions, etc”, isn't just an enterprise-scale problem, any multi-tenant system can and probably will hit it.
Working out who can access what can sound simple enough, but it gets rather less pleasant when the rules can be set with more complex ACLs¹ and because people can move around dynamically it is both potentially resource heavy to derive and difficult to cache² both safely and³ efficiently. It is natural to think “well, we can simplify the permissions model”, but you really can't when selling to different enterprises: many have their own idiosyncratic workflows, or local tweaks if using an “industry standard” workflow, and they will make a noise if your software to support them without extra tricks on their part.
We are at a much smaller scale⁴, in another industry, but this is an issue we have to be very careful about.
--------
[1] Is this person in a given group? Does that give or remove permission? Can they just access, or edit, add, …? also: different elements on the same screen could have very different ACLs to each other and at different times in a process
[2] missing changes for a time could cause significant issues if users are working on something commercially important or otherwise sensitive
[3] Safe is easy: don't cache at all. Efficient is easy: don't care about a bit of staleness and accept a bit of “eventual consistency”/“eventual correctness”. Achieving both takes a pile of resource even with a great design.
[4] We don't have to worry about consistently spreading data and processing over a set of DCs as our product has natural borders between tenants so splitting off into distinct DBs⁵ is an easy answer to some of the scale & efficiency issues.
[5] rather than needing everything in on “public” system because anyone can potentially want to share access with any other user.
I will admit I have waned enthusiasm a on Figma over the past couple of years. I find the UI churn confusing. The new features, i.e. dev mode and variables, feel out of place. I find the plugin ecosystem cumbersome. Doing simple things has become complex. I'm putting out real "who moved my cheese?" energy here I know. I suppose I'm wondering if others feel the same.
Create a product sell or IPO. Revenue pressure increases. Product cost is increased or staff is cut. New software takes crown. Rinse and repeat.
Is this an uncommon use case?
When my devs just copy whats in Figma dev-mode they get so much stuff wrong.
I work in complex SAAS product design. Basic things I can do in CSS I can't do in Figma. Things like a table? Yeah it is entirely faked and awful in Figma. Don't even get me started on anything more complicated than flex rows and columns.
Half the debate over designer/dev handoff in the industry right now is simply because of Figma's limitations and the refusal of designers and front-end devs alike to learn HTML and CSS.
We need a Blender-like tool for web and app product design. Highly capable and advanced, you aren't expected to know all of it, and it can do anything you want it to.
I need a tool that is more than just a fancy rectangle drawer.
HTML and CSS are expressive, have a vast selection of libraries and tools, and can actually result in shippable code. Designers and front-end devs should learn and use it.
But I don't see the point in creating a design tool unless it's meaningfully simpler than HTML/CSS. I reach for Figma when I need to quickly mock up a dozen iterations using our design system and fancy rectangles. It's fast enough that I can make mockups in realtime during discussions with developers and subject matter experts. But if I'm actually going to take the time to set constraints to make things flex properly or make a real table then why not use HTML and CSS directly?
Figma is a great tool for 90% of basic and boring design. A lot of product design is not just basic and boring, and a lot of stuff I need simply cannot be reproduced in Figma. So yes I do just write the code directly, but that doesn't let me explore those complicated layouts and iterate on them visually the same way I could if it was HTML/CSS in a Figma-like design canvas.
The problem then was that the designs could be too cumbersome to implement (and also that you couldn't share files with developers as easily, but Sketch has the same problem). You can really do just about anything in PS/AI, whereas with Figma and Sketch it's almost like they limit you to what an average developer can implement with CSS.
That being said, we're in the age where you can do pretty much anything with CSS, and I totally agree with you that Figma's controls are very basic (especially for typography, there's just not enough options).
FY Ended December 31, in millions except percentage
| 2023 | 2024 | YoY
---------------|--------|--------|-------
revenue | $505 | $749 | 48%
gross profit | $460 | $661 | 44%
op ex | $534 | $1,539 | 118%
net income | $738 | $(732) | (199)%
free cash flow | $1,041 | $68 | (93)% FY Ended December 31, in millions except percentage
| 2023 | 2024 | YoY
---------------------------|------|------|------
research and development | $165 | $751 | 356%
sales and marketing | $201 | $472 | 134%
general and administrative | $168 | $316 | 88%
| 2024
---------------------------|------
cost of revenue | $25
research and development | $463
sales and marketing | $187
general and administrative | $184
total | $858
| 2023 | 2024 (adj.) | YoY
---------------------------|------|-------------|------
research and development | $165 | $288 | 75%
sales and marketing | $201 | $285 | 42%
general and administrative | $168 | $132 | (21)%
total | $534 | $705 | 32%https://news.ycombinator.com/item?id=27701617#27702669
Then that AI feature they highlighted was pulled off production because it was cloning iOS.
The AI heavy product dump we just got are lessons from that time.
From an accounting perspective, it was an $800 million stock-based compensation expense, though it didn't really cost Figma anything.
So the numbers for the year before IPO may have no relation to future.
I mean, you’re technically correct¹ but that’s not exactly helpful because the inverse is also true: You can define any space as “crowded” if you widen it enough.
That is to say it is perfectly plausible I am wrong and the space was crowded, but that argument doesn’t really prove or disprove it.
> That was the point really, they entered a crowded space & re-defined it with their offering.
Especially if you allow someone in the space to redefine it. At that point all bets are off and anyone can claim anything.
¹ The best kind of correct: https://www.youtube.com/watch?v=hou0lU8WMgo
The product space they entered, UX design tooling, was very crowded. Sketch and InVision were the kings and there were a dozen other reasonable options to choose from (including ones in browser with real time collab and other interesting tech).
Figma entered that market later and won on a combination of technology and product innovation aka execution.
But they absolutely entered a crowded market.
I have nothing but respect for Figma's tech, but I'm not really sure this lesson is generalizable to 99.9% of other people. By all accounts Evan Wallace has skills and talent the vast majority of software developers don't have and never will have. The reason Figma was able to succeed in this space is that their engineering team was like the 90s-era Chicago Bulls of software development.
And to emphasize, that's one reason I'm very happy for Figma's success. Figma didn't succeed because they "got lucky", or just happened to be in the right place at the right time, or had great marketing. They succeeded because they were able to create a brilliant technical solution to a problem that lesser engineers and engineering teams were simply not able to solve.
Huge contracts are built to extract as much wealth from the customer as possible without letting the victim know. Not by engineering talent. Huge contracts are what make Figma a success story.
Every successful company had some sort of edge. Some sort of advantage that other companies in the space don't have. For Figma that was high level tech execution. For something like, say, LaunchDarkly, that was a killer enterprise sales team. For something like Liquid Death, it was pure marketing and positioning. Just to use some other examples of companies that launched into crowded spaces and succeeded.
It could be anything, but it's always something, and no advice should be generalized.
> In the section on Photoshop to Sketch, we discussed an underappreciated factor in Sketch’s, and by extension, Figma’s, success: That flat design shifted the category of design software from professional creative software to something more akin to an office suite app (presentation software, like Google Slides, being the closest sibling). By the time work was starting on Figma in 2012, office suite software had already been long available and popular on the web, Google Docs was first released in 2006. This explains why no other application has been able to follow in Figma’s footsteps by bringing creative software to the web: Figma didn’t blaze a trail for other professional creative software to move to the web, instead Sketch blazed a trail for design software to become office suite software, a category that was already successful on the web.
It's still difficult for me to wrap my head around that this has actually happened, because it's unheard of in other media editing industries for software to go backwards in capabilities. I always compare it to if movies suddenly stopped needing special effects, then of course the entire existing movie-making pipeline would be re-evaluated.
They got a huge influx of users when image editing AI started to be a thing, I'm not quite sure that they haven't already conquered most of new users that could join them.
[1] https://techcrunch.com/2025/04/15/figma-sent-a-cease-and-des...
“Used the moment” sounds a lot like surviving a punch and then asking for help. If you think that’s scheming, maybe revisit who threw the first punch.
In the example here: people would bet by either buying $100 worth of Figma shares, or they could buy $50 worth of put options and give $50 to the developers of Penpot.
Would something like that be legal or does it violate any type of trading regulations?
I would love to be a reverse—VC
Should I make a mock system, see how many people would be willing to sign up and make a pledge to their favorite projects?
(I do not recommend this)
Is this an IPO where participants (public) will make long term money of it’s already at the top and this is the final stage of “finding someone to hold the bag” and in this case eventually — the public i.e the retail trader, mostly?
Seriously, are people starting to replace Figma with just basic LLM or simpler LLM-based solutions? I'm just trying to understand the timing of the IPO and the market. We used to use Figma, but dropped it as first phases of product design loop ended. Basic LLM does not feel there yet, but it does feel like it could be there very quickly.
If the companies are so confident of their trading ability then they should stop their existing business and become trading companies.
With all the AI tools, the market is in a transition period.
Those transitions are crucial for a product's success or failure. For example, the transition from web to mobile with the iPhone, along with the growing pains of using Photoshop and Illustrator for mockups, opened the door to Sketch. Then, the evolution of web apps, like Google Docs, opened the door to Figma (while other products like InVision had a drastic fall). What they accomplished in a web app is an impressive engineering feat, so they have an excellent engineering team.
The good: Figma is implementing multiple product updates to capitalize on the "AI wave". The Figma Make in beta is very similar to Vercel's v0 (and others). Still, the tight integration with Figma could help them leverage their current subscriptions and attract designers, PMs, and developers. Recently, they released an MCP server in beta that enables AI coding tools to obtain information from designs. While many designers may disagree with me, I believe that at least they are trying to maintain a leading position in a rapidly shifting market.
The bad: They are diversifying their product offering too much, trying to compete on many fronts. Figma Site competes with Framer and Webflow, and Figma Buzz aims at digital marketing, which is usually covered by many tools (including Canva). Figma Slides is ideal for designers who use Figma daily, but it may not be as user-friendly for those transitioning from PowerPoint or Keynote. They switched the focus from the Design->Dev process that made them successful. The dev mode still doesn't resolve many issues, such as versioning, and the variable features seem half-baked; component handling needs more love, and the prototyping options are still limited.
The future... is hard to tell. In terms of UI design tools, they are the leaders. Penpot is far from being stable; Sketch is similar, but their web experience is not as good as Figma. Unless a new player enters the market, their biggest threat is a significant disruption caused by AI tools... but the tools I've seen so far are not different from Figma Make.
Now prepare for price increases, lock-ins and many threads of people looking for Figma alternatives.
The ones cheering already have stock ready to dump it on the public markets on retail.
I know of excalidraw and perhaps penpot are there anymore?
Going public makes their shares liquid. It's (probably) not reasonable for the company to repurchase that equity or to pay employees pure cash comp.
Anyway, congratulations to everyone at Figma and good luck.
That said, today it's an incredibly good design tool - worth checking out before shareholders start the enshittification process. Congrats to the devs / founders for making it all the way to an IPO!
But Figma itself is excellent at what it does.
Judging by the amount of fairly traditional companies holding Bitcoins, it would seem like holding Bitcoin is no longer spooky. I guess it makes sense when the financial environment is slowly turning into one without any regulations, Bitcoin will thrive in that sort of market.
This business model isn't sustainable for individuals, so they're going to naturally be upset. If the B2B market is more lucrative for Figma then they have every right to optimize for it, but they're going to pay the cost in user goodwill. Many startups go through this process.
Shopify, Cloudflare, Zoom, Spotify, Roblox, and Coinbase are all notable examples.
I mean yeah, it's cool and all that the employees and owners get a pay out, but IPOs are generally bad news for users, and I'm sure I'm not the only Figma user here, so makes sense that people are cautious about something that is usually bad news for them.
> Figma provided an alternative to the evil Adobe empire that was actually better
That's the crux, because generally IPOs mean that they'll now slowly turn into whatever it was they were supposed to fix. Maybe Figma will be the 1-in-a-billion products that won't suffer that fate, but it's understandable that people are now starting to casually look for alternatives, given most people's experience with IPOs.
Figma’s cloud-first nature never also sat well with me… I still have the source PSD files for my earliest works from 25 years ago, which can still be viewed and edited perfectly. Will that be true of my Figma documents in 25 years? It’s not even a question with Sketch.