Matt also shares the early-days playbook of writing down the twenty most relevant people in your space and getting in front of them first, why leading with developer experience beat leading with performance or security in Netlify’s early messaging, and why the dev vs. non-dev binary is about to dissolve the same way reading and writing did after the printing press.
What we talked about
Matt Biilmann’s background: from Copenhagen musicology to San Francisco engineering
Matt grew up in Copenhagen and did a bachelor’s in musicology and comparative literature at the University of Copenhagen, then worked as a music journalist for Danish Radio while doing a master’s in cultural studies. He was fascinated by why music makes sense to humans and how foundational technologies, like written music notation, shape entire cultures. He sees classical composers as the first programmers: people who sat down and wrote a structured program over time, to be executed by the machine of an orchestra. The ability to hold a whole program in your head used to define both. He had been coding since age ten on a Commodore 64, kept building on the side through university, and after following a Spanish girlfriend to Barcelona, pivoted to engineering full-time once it became clear there was no market for writing about music in Danish in Spain.
From senior Rails engineer to CTO in three years
In Spain, Matt joined a startup that ran the largest hostel booking site and the second-largest social network in Spain, and whose core business was building roughly a hundred websites a week for small and medium businesses across Europe. He started as a senior Ruby on Rails engineer, and within three years went from developer to tech lead to director of technology to CTO. He then co-founded a cloud-hosted multi-tenant CMS in Spain with the same founder, and moved to San Francisco to scale it. That product, Webpop, stagnated around a hundred thousand dollars a year in revenue, and Matt began to believe that the monolithic CMS model was the wrong bet. Front-end developers were still treated as pseudo-developers who sliced PSD files into HTML and CSS for “real” developers. Matt thought that if you gave them the right tooling, they could own the full user experience end to end. That conviction led to a small MVP called Bit Balloon, which became Netlify after Matt convinced a friend in Denmark to sell his apartment, move to the Bay Area with his family, and start a company with no salary.
The early days of Netlify: the list of twenty people
The first year of Netlify was bootstrapped, with Matt building the whole product himself. When co-founder Chris Bach came on board, he pushed Matt to write down the twenty most relevant people in the space who should know about the product. The list included people like the founders of Heroku, Tom Preston-Werner (who had created Jekyll and GitHub Pages), agency teams behind tools like Middleman and Carrot’s Roots static site generator, and Harper Reed, who had scaled the Obama campaign with Jekyll and S3. The thesis was: if at least half of these twenty people thought Netlify was cool, the team could trust the idea and spread it outward in concentric circles. If they didn’t, the team should rethink.
Watch what people do, not what they say to improve your product
Matt’s hard-won lesson from his earlier product: when you sit down with an early adopter and show them what you built, they will almost always say something nice. If they go and build with the product, that’s validation. If they don’t, every other user who shows up cold will be even more lost. Listening to what people do, not what they say, became a discipline Matt carried into Netlify from day one.
Why developer experience beat performance and security as the lead message
Netlify in 2015 had a globally distributed CDN, CI/CD pipeline, atomic deploys, rollbacks, and branch previews. The performance and security advantages over a typical WordPress site of the era were enormous. But when the team led with that messaging, it didn’t land. Developers said it mattered but didn’t act on it. What landed was leading with the speed and ease of going from nothing to something live on a URL. Once they had felt that, the performance and security story followed naturally. Matt sees this as a typical pattern for developer tools.
How “agent experience” got coined
In late 2022, Netlify was in a tougher PLG spot as a competitor took ownership of the Next.js ecosystem, and the team had started moving upmarket into the composable web experience category. Then ChatGPT launched and Matt knew he didn’t want to bolt AI agents onto the product reactively the same way many SaaS companies did with bad results. Instead, one pillar of the AI strategy became that he wanted Netlify to become the preferred deployment platform for AI once it could actually build for the web.
Netlify launched a ChatGPT plugin in 2023 that allowed zero-friction publishing and started seeing roughly a thousand sites a day created from ChatGPT. When Devin launched, it was clearly ahead of its time but the direction was unmistakable. When Bolt and Lovable launched at the end of 2024, the team was already paying close attention. On a call with a principal engineer about the functions compute primitive, Matt asked: what would we do to make this better not just for developers, but for agents? What should the agent experience of it be? In January 2025, he gave an internal all-hands talk arguing that DX had been Netlify’s North Star for ten years, and AX would be the North Star for the next decade. Since then, daily signups have grown more than 10x and daily new paying customers have grown around 500x.
The four pillars of agent experience
Matt thinks about AX holistically and breaks it into four pillars.
- Access: how does an agent even get into your product, with or without a human in the loop? Netlify’s “deploy anonymously, claim later” pattern has spread across the industry, but identification of agents acting on behalf of humans is still an open problem; Auth0, Coinbase, and Cloudflare have all shipped early answers.
- Context: agents are simple loops of LLM calls and tool calls, and what’s in the context window determines whether they even know your product exists and how to use it. This is where markdown-friendly docs, copy-pasteable snippets, and MCP all matter.
- Tools: agents will try to use your product, the only question is whether it’s a good experience. CLIs, APIs, SDKs, MCP servers, and skills all feed this pillar.
- Orchestration: not just how agents come into your product, but how people kick agents off from your product. Linear has been excellent here and the same goes for Linear’s recent integration of Netlify Agent Runners. Asana, by contrast, built its own agents inside Asana, and Matt argues that approach won’t survive: people who have invested in their own Claude Code or other configured agent stacks don’t want random vendor-specific agents in their workflows. The loop has to go both ways: agent to product, and product back to the user’s own agents.
Walled gardens won’t survive the agent era
Traditional SaaS companies are tempted to wall off their data and control which agents can touch it, because on paper that looks like better monetization. Matt’s view is that this strategy backfires. People will start pulling their data out so their own agents can work with it, and once they’re working with that data outside the product, they’ll ask why they’re putting it into the product at all. He’s already seeing this happen with several tools.
Code factories and the temporary state of code review
Matt expects current developer-led code review of agent-generated code to be a transitional state, not a permanent one. The end state isn’t developers writing all the code by hand again, but developers no longer reading most of the code, with validation and instrumentation replacing line-by-line review. The tooling for that isn’t production-ready today, but he expects it to start producing real production use cases within a year, at which point a sharp acceleration becomes available to teams who adopt the flywheel.
From 17 million developers to 3 billion
Until the end of 2024, Netlify’s realistic addressable audience was around 17 million professional JavaScript developers. The shift Matt is betting on takes that number to roughly 3 billion people, anyone technical enough to use spreadsheets and have an internet connection. Computer literacy used to mean knowing how to use a computer; now it’s going to include being able to build software. Matt expects this to mirror what happened after the printing press, when reading and writing went from being the specialized profession of scribes to a baseline expectation for almost any job. Specialists will still exist, but the binary of “developer or not” will dissolve. He uses an example close to home: a childhood friend who’s a chiropractor recently messaged him with a link to a clinic website he had built himself on Netlify, someone who would never have been a Netlify user before.
Agent Runners and “Start from Agent Runners”
Netlify launched Agent Runners Spec in 2026 as a bet on CLI-based coding agents from the frontier labs themselves on the thesis that when a single company owns both the model and the code harness and can run reinforcement learning across the loop, those agents will be very hard to compete with. Netlify built its own sandboxing infrastructure to spin them up and tie them into the existing deploy preview workflow. The day after this episode was recorded, Netlify was launching “Start from Agent Runners”, which lets users go straight to Netlify and prompt a new project into existence with Claude Code without ever leaving the platform. It is Netlify’s first step toward being a full end-to-end platform for building, while staying open: the agents are the same agents you’d use locally, and you can still get the same repo and push from your machine.
Redesigning UX for a much wider audience
The most interesting challenge ahead, Matt says, is rethinking Netlify’s user experience for an audience that is no longer a relatively homogeneous group of JavaScript developers but a much wider spectrum, from hardcore engineers to chiropractors. The redesign focuses more on outcomes and less on technicalities, without talking down to anyone. Matt doesn’t see this as becoming “a builder tool” instead of a developer tool, he sees all of these new users becoming developers, the same way everyone became a “writer” after the printing press, even if they aren’t all professionals at it.
Transcript:
[00:00:00] Victoria Melnikova: Hi everyone. My name is Victoria Melnikova and I welcome you to Dev Propulsion Labs, our podcast about the business of developer tools. Today I have CEO and co-founder of Netlify, Matt Biilmann. Hi Matt. How are you today?
[00:00:21] Matt Biilmann: Hi, great to be here.
[00:00:23] Victoria Melnikova: Thank you so much for coming. I know it’s hot in San Francisco and it’s becoming more difficult to do things because it’s a way too exciting to be outside. But we thank you for being here today, and we have quite a few questions to discuss. And I would like to start actually with your background because I was shocked when I did research on you. I’ve never seen a bachelor in musicology as a specialization for anyone. So tell us about your background. So you are from Denmark, you are Danish, and you went to University of Copenhagen and studied music.
[00:01:01] Matt Biilmann: Yeah. I grew up in Copenhagen and took a bachelor in musicology and comparative literature. Then actually started working as a music journalist for the Danish Radio while doing my master’s in cultural studies.
[00:01:17] Victoria Melnikova: Wow.
[00:01:18] Matt Biilmann: So the obvious background to build developer tool companies. Had a fun story actually — a long time after, when I was in San Francisco, we closed the seed round for Netlify. Just the day that we closed that round, I saw my best friend back from musicology in Denmark post on his Facebook feed that he had just closed a similar seed round for his tech startup. So I guess there was something in there.
[00:01:51] Victoria Melnikova: For the VCs that are looking for promising founders — go to Copenhagen and look for music students.
[00:01:57] Matt Biilmann: Find the musicologists.
[00:01:58] Victoria Melnikova: So who is a musicologist? What does this person do?
[00:02:02] Matt Biilmann: It’s a university education, so it’s not a practical education in being a musician — that’s at the conservatory. You do have a bunch of practical courses. I got trained in choir conduction and band leadership and piano and singing and so on, to some degree, but it’s not like a musician — you’re not trained to be a musician. It’s similar to studying literature. You’re studying a lot of the history, the philosophy of aesthetics. What kind of drove me was just like, I was so fascinated by why does music make sense to us and matter to us. It’s very universal — you have music in pretty much every human culture. And at the same time, it’s different from language in the sense that it doesn’t try to convey some very semantic meaning. It’s not a rational system of meaning in the same way. But at the same time, it obviously means something to us very fundamentally. And sometimes more fundamental than words and language, in some ways. So that was kind of my motivation for studying it. In some ways it’s like part of understanding humans and what makes us human, right? Like why do these things make sense to us? And that’s why I got into studying literature, and later on modern culture — that’s sort of the broader field of modern aesthetics. How do we create culture between humans and why does it make sense to us?
[00:03:46] Victoria Melnikova: Yeah. I mean, it’s wonderful. I studied seven years of piano. And I actually saw that there are a lot of similarities between math and music composition, because the tones and everything — it’s very systematic.
[00:04:03] Matt Biilmann: Yeah, especially the traditional sort of classical music. It was interesting when I was writing my master’s thesis that I never finished, in cultural studies — I was gonna write about music and technology. But from the point of like the really foundational technology where written music notation is a very specific technology that got invented at a specific time, and was very unique to Western classical music. Most music systems are mostly practical. This was very unique that we started having this notation system, and it turned into this whole world of symphonies and like massive works over a long time with a lot of complexity that has a lot of similarities to math and abstract reasoning. In a certain way, I always like to say that the classical composers were like the first programmers. They were the first ones that really sat down and wrote down this kind of program over time to be executed by this machine of an orchestra or a quintet or whatever. And you had to sort of hold that whole structure in your head and think through it. So I think in that sense there’s a lot of similarities in the skillset that used to define programmers and that used to define classical composers. Like, now the programmer one, it’ll be interesting to see how it changes, because that ability to hold a program in your head is kind of becoming maybe less central than what it used to be.
[00:05:40] Victoria Melnikova: Yeah. So I’m assuming having an analytical mind somehow made your way into Rails engineering — like that was your next step.
[00:05:49] Matt Biilmann: So I mean, I was programming computers since I was 10 years old. I got a Commodore 64, and back then the only thing you could do with it was like typing stuff in. It didn’t have a mouse or anything like that. You turned it on and you got a little prompt, and you had to type stuff. You could load games and so on, but you would even get some games from computer magazines that was just the listing, and you would sit and type them in, and then you’d hit enter, then you’d get some syntax error, and then you had to start understanding like, why doesn’t my game work? That sort of became the start of programming computers, and the start of the whole fascination with the fact that you could have somehow, inside this symbolic machine, some kind of world that existed and people could interact with. That was kind of my fascination with computers. And then the fascination with the web came when I first got access to it and sort of realized — it was pretty mind-blowing at the time — oh wow, you can just put something up on a domain that you buy somewhere, and suddenly everybody who has an internet-connected computer in the whole world can go there and see it. That was pretty wild. It completely changes distribution of everything. But it was always a passion and a hobby that I was doing alongside work and alongside studying. And I often felt guilty. I had an exam where I had to hand in a paper on modern American literature, and I was spending all my time building this distributed system for social media around an online multiplayer game ecosystem. It felt like, “I’m wasting my time here, I should be doing my American literature studies.” But —
[00:07:44] Victoria Melnikova: I’m sure you have no regrets now.
[00:07:47] Matt Biilmann: In the end it worked out pretty well.
[00:07:49] Victoria Melnikova: So it led you to the US, right?
[00:07:53] Matt Biilmann: Sort of indirectly. First I met a girl from Spain, and I went there and visited her. She came and visited me in Copenhagen. I went to Spain again. She came again. And then I was like, okay, I’m gonna go to Spain for at least three months and finish up my master’s thesis in cultural studies that never got finished. That never got finished, but that was my plan. I went there, I thought, okay, I can work a little freelance from there and I can write my thesis, it’ll be fine. And quickly discovered that, okay, I’m gonna probably end up being in Spain a bit longer than three months. And also discovered that the market for writing about music in Danish in Spain —
[00:08:35] Victoria Melnikova: Is very limited.
[00:08:36] Matt Biilmann: It’s a very small town, and without any connections, and I didn’t speak Spanish — it’s not gonna happen. So I kind of had to start figuring out a plan B and I started just building stuff. I’d always been programming. I think one of the first things I built was this Sudoku challenge, when Sudoku was a hit, where you could land on a website, you would get a Sudoku, when you solved it you could share — you could send an email to a friend that would get the same Sudoku, and when both sides solved it, you would get the timing of who did it fastest. Then I started building this crazy browser-based space game with a procedurally generated universe. I found this old paper from an astronomical journal from like the seventies, describing the formation of solar systems and planetary systems from an accretion disc. And they had this whole simulation meant to be run on a supercomputer in the seventies. And I figured out, oh, you can run that during a web request today on a regular server. So I could generate this infinite galaxy where you could get super detailed solar systems and so on. I worked on that and I showed it to some people, and then got hired by a Denver-based startup as one of the first engineers to build a social media network, back when everybody was starting to do that. It didn’t go anywhere, but I learned a lot from it. And then got hired by a startup in Spain, where we did a lot of different things. The company ran the largest hostel booking site in Spain, the second-largest social media in Spain. But the core business was building websites for small to medium businesses across Europe at a very high scale. We would build something like a hundred websites a week.
[00:10:37] Victoria Melnikova: Oh my God.
[00:10:37] Matt Biilmann: And it’s funny, because it was actually my first real paid job — the previous startup paid me stock options, which was like my first real paid job as a developer. And I started as a senior Ruby on Rails engineer in my first role. But then within three years went from developer to tech lead to director of technology to CTO of the company.
[00:11:01] Victoria Melnikova: Wow.
[00:11:03] Matt Biilmann: That sort of became my first foray into being a technologist. And then I started a company in Spain together with the founder of that company. We took a lot of the experiences of the platform we had built there and built a cloud-hosted multi-tenant CMS. And he was the one that convinced me to go do that in San Francisco. We spent a couple of years doing visas and everything, came to the US working on that. We ended up sort of parting ways because we had started another project back in Spain called Domestika, that became this big network of designers and creatives, and he went to focus fully on that and has turned that into an amazing company today. And then I took our Webpop, as it was called, and we were kind of stagnated a bit — we were stuck in revenue around a hundred thousand a year. And I started thinking it was not the right model for the future. It was a really cool product in many ways — like, we had serverless functions in JavaScript in 2010, a lot of concepts that I think were ahead of their time. But it was still this idea of a monolithic CMS with backend, frontend, everything together. And I started getting this belief that we would start taking the actual frontend and treat it as a real developer discipline. Because at that point, a frontend developer was still kind of seen as a pseudo-developer that would take some PSD file and slice it into HTML and CSS and then hand it to a real developer, like a Ruby on Rails developer or something. I started thinking, well, there’s no reason if we give the right tooling and platform that these frontend developers can’t build the whole user experience end to end, and then we can decouple the backend and have APIs and services for that. And that kind of one thing led to another. I started a small MVP in that space called Bit Balloon, then convinced a friend of mine, a good friend of mine back from Denmark, that it was a bad idea to have a well-paying job there and instead he should sell his apartment and move to the Bay Area with his family and stop having a salary and go. And he did. He did that. And we started together more than a decade ago now.
[00:13:29] Victoria Melnikova: That’s crazy. I mean, it almost sounds like you just had a calling and you had to follow it — it’s like the strong pull.
[00:13:37] Matt Biilmann: I always felt like building something in one form or other — that was kind of like the bug that bit me. And I think that early moment where I realized, wow, you can just build something on the web and put it out there, and it’s available to everyone — that was the moment where something was like, okay, someday I gotta build something there. Because you can, and it’s amazing. And then I got into building products for developers pretty early on, and got really hooked by that because it’s this multiply effect — you’re giving all these builders tools and then they go build and create stuff. That’s just amazing to see. It’s really fascinating.
[00:14:26] Victoria Melnikova: So Netlify is a decade old at this point.
[00:14:29] Matt Biilmann: Yeah. A bit more, like 11 years. 11 years here in a few days.
[00:14:33] Victoria Melnikova: Yes. So let’s talk about the early days of Netlify, because it’s a true PLG model, right? What did you do in the early days? And I mean, now you have so much experience also with other dev tools. Looking back, what were some steps that led Netlify to be that successful?
[00:14:57] Matt Biilmann: So right when we started, the first year, we were just bootstrapping. We were literally just two of us, and I was the one building the whole thing. And I think one of the things we did well was, just when Chris came aboard, we sat down and he kind of pushed me — who are the 20 most relevant people in this space that should know about this product, and that should care? We kind of made a list, just of those 20 most important people.
[00:15:28] Victoria Melnikova: Do you remember who was on the list?
[00:15:29] Matt Biilmann: And we made it. There were people like the founders of Heroku, like Tom Preston-Werner from GitHub that had created Jekyll and GitHub Pages, people at a couple of agencies that had built tools like Middleman or Jekyll or Carrot. Carrot had this static site generator called Roots that they were using for real things and had talked about it. Harper Reed, who did the Obama campaign back in the day and had written about how they managed to scale that by using Jekyll and S3. It was all of these people where we felt, okay, these people ought to know about what we are doing. And if we are doing it right, when we get in front of them, at least half of them should say, “this is really cool.” If they don’t get it, then how is everybody else gonna get it? Then we should really rethink. So that was kind of the list, and we thought about that process a lot. But most of these tools, they kind of spread in concentric circles. You have some people that are, for different reasons, the really early adopters and the ones that will spread the word and validate, and will be the first ones willing to jump on a new tool. And we really made it our mission to like, we gotta get in front of those people first, and we gotta listen to them and make sure that we are building something that they think is really cool. Because if they don’t, they’re probably right. They know the space enough that if they don’t get it and they think we’re doing something wrong, we should probably revise. But on the flip side, if they get it, then we can take what they get and spread it to the masses. So I think that was one of the really good initial steps. And I think I had learned also from building Webpop and so on. The other thing is to be very ruthless on what people do and not what they say. If you get in front of someone that should be an early adopter of your product, you sit down with them and you show it to them, one thing is certain: they will always say, “oh, this is really cool, thank you so much.” Unless they’re really a jerk, they’re not gonna sit down and be, “ah, yours probably really sucks.” So they’re always gonna say, whatever you show them, they’re probably always gonna say something nice. That’s just human nature. It would be really weird to just be like, “this sucks.” But then what happens after is what matters. If they go and start doing something with your product, that’s real signal. And on the flip side, if they don’t, after you sit down with them and you’ve shown it to them and you’ve talked it through with them, then that’s also very strong signal, because all the other users coming to your product won’t have that luxury. They will be lost. So that was one lesson I had really learned from my first product, where I think I listened more to — because it was a cool technical product — I kind of took the feedback, “oh this is really cool,” and so on. But then they weren’t really building stuff with it afterwards. And it took a while to learn that that’s the real feedback.
[00:19:04] Victoria Melnikova: Mm-hmm.
[00:19:04] Matt Biilmann: It’s not what people tell you. It’s what they do. And then the second thing was just to really focus — and this is obvious for a PLG product — but you’ve gotta really focus relentlessly on the first experience. The people you don’t sit down with, with a laptop and give it to them and so on — they’re gonna hit your website from somewhere, and then you have very short time to get them convinced they should take some next step. And then when they take that next step, you have a very short time to show them that that step creates some value. So we were very obsessed around that initial: how do people get to a point where they see some value very fast? And for us it was: what is the fastest path to have something on a URL? How fast can we get people from not having something on a URL to having something on a URL? Then, how can we do it in a way where afterwards they also realize the power of it? This was actually an interesting learning really early on. The nature of what we did — we had built a globally distributed CDN and CI/CD pipeline that allowed for rollbacks and branches and all this stuff. We could guarantee amazing performance, amazing scalability, and amazing security. Especially compared to all the tools people typically use back then. The performance of some random WordPress site in 2015 and the security of a random WordPress site versus a static site on Netlify in 2015 was miles apart. And at the same time, what we learned was that if we led with that messaging — of performance, of security — it didn’t matter to developers.
[00:21:04] Victoria Melnikova: Yeah.
[00:21:04] Matt Biilmann: They would say it matters, but it doesn’t really matter. What mattered was leading with: this is how fast you can get something on a URL. And then once we had shown them that, then it was about showing, and look, what you got on a URL is much faster than what you would otherwise have done. But we had to lead, even with that gap in outcome, with the developer experience — the ease and simplicity of working with our tool — that’s what we had to lead with to win them over. And I think that’s very typical for development tools.
[00:21:42] Victoria Melnikova: So it’s interesting because you are showing this empathy towards users, right? Like you put yourself in their shoes, try to imagine what it is that drives them. And one way to test that is actually dogfooding. And you dogfood Netlify all the time.
[00:21:58] Matt Biilmann: That’s another critical thing. As soon as I could, I started building Netlify with Netlify. As soon as possible. And of course you always have to do that and have to obsess over using your own tool all the time and be a hard critic of your own tool and push it forward.
[00:22:16] Victoria Melnikova: And now fast forward to 2026, when you sit down with agents to build something with Netlify and something doesn’t work — that’s how you coined the term agent experience, right? That’s how it came about.
[00:22:30] Matt Biilmann: Yeah. It came about — it was pretty in 2022 when ChatGPT came out. We were actually in a bit of a tougher spot, because suddenly some of our PLG motion started being threatened by Next.js being owned by a competitor and being super popular. So we started moving more upmarket where we were further ahead, which honestly was not as natural for me as a motion. But we kind of had to, and we were building it into a new category of composable web experience and so on. And then ChatGPT came along, and everybody had to start formulating an AI strategy. And I was very clear that I definitely didn’t want to just reactively slap AI agents all over our product. I think a lot of companies did that with really bad results at that moment. And I also couldn’t have like two different strategies. We were in the middle of doing one thing, and we couldn’t do five different things at the same time. But one core pillar of our AI strategy back then became: we should aim to be the preferred deployment platform for AI, once AI got intelligent enough to build stuff on the web. And that seemed very much like science fiction with the first ChatGPT. You could barely get it to write a coherent function or anything like that.
[00:24:01] Victoria Melnikova: Or even text.
[00:24:02] Matt Biilmann: Or even text. But I was still pretty convinced that, okay, if this whole thing becomes something real at some point — I probably thought it was more like a decade away, but it was gonna happen. And that meant we started doing various things to go in that direction. So when ChatGPT launched their plugin marketplace, which is now barely functioning anymore — I don’t really know what happened to it, but it was a big launch — we immediately launched a Netlify plugin for ChatGPT that allowed zero-friction publishing to Netlify. So from ChatGPT, if you had built some little website or something, you could just say “deploy to Netlify.” It would deploy to Netlify, no login or authentication. And then it would give you a link, and then it would also give you another link where you could go claim the project if you actually wanted to keep it and do something with it. And that was in 2023, so that was pretty early. We gradually started seeing a thousand websites a day created from ChatGPT, which was really interesting because it was not really mature for that purpose at all. But we started documenting these flows and how we had done this plugin. And then early on when Devin launched, it was like building with Netlify as a default publishing layer. When Devin launched, it was way too early. Very ahead of its time. And it got derided a lot because they made some big claims and maybe it couldn’t quite get there. But the vision was clear enough. And today we are very much seeing these autonomous coding agents going and doing work. I believe that was a sign of: yes, it’s not ready now, but just imagine the models keep improving at the speed we are seeing — this kind of flow will happen. So we started really learning from that and saying, what do we need to do to get better? We started talking to them and being like, “Hey, how does it work for your agents? What could we improve?” And then by the end of 2024, when Bolt and Lovable launched, Bolt had built a direct deployment integration into Netlify. It’s funny because they’ve been around for a long time, and suddenly Eric writes me one day like, “Hey, we’re launching something in a few days and we might need to bump the rate limits on our API account.” Like, didn’t even know you had an API account. But we’ll pump them, we’ll help out. And suddenly we just started seeing a massive amount of agent-generated projects come in.
[00:26:53] Victoria Melnikova: Oh, yeah.
[00:26:53] Matt Biilmann: Of course we took that extremely seriously, right? It’s always been a part of our strategy. So again, we really just wanted to learn from them. And I remember at the end of 2024, I was sitting on a call with one of our principal engineers, and we were talking about our functions compute primitive. And we were talking about: what would we do to make this not just better for developers to work with — we thought a lot about the developer experience — but what would we do to make it better for agents? What should the agent experience of it be? And just as I said that, I was like — “agent experience,” that’s definitely a thing we need to incorporate in how we work. And then I gave an internal talk at our all-hands at the start of January 2025, where I basically came to the team and said: AX, agent experience, is gonna be a new term. It’s gonna be incredibly important in the future, and it’s gonna be our North Star from a product perspective. Like, DX was our North Star for 10 years; in the next decade, agent experience is gonna be what’s gonna matter the most. And that was still very early. I think a lot of people still thought of agents not as a Devin with a real brain, but as purely like an Allowable in the early days or something. But it was my thought that these things would come together, and we would get to this point where you start having your own autonomous agents that you have a relationship with, that work for you and so on. And almost any product is gonna have to be great for those agents to use, or it’s gonna become irrelevant. And that was sort of like our really early realization. And I wrote that article in January 2025. And then we just started orienting our whole roadmap around it. And since then, we’ve more than 10x’d daily signups on the platform — something like 500x our amount of daily new paying customers on the platform — and now have the strongest PLG motion we’ve ever had in the history of the company. And it has really been from that bet on: we got to build for agents and for the humans using agents. Like in the end, hopefully there’s still some human somewhere that’s trying to get something done. But you’re just not serving that human well if they’re trying to get it done through an agent, and that agent stumbles when it uses your product.
[00:29:37] Victoria Melnikova: So if we were to summarize agent experience — can you define a few pillars on which this term stands? Because we hear like CLI, documentation…
[00:29:47] Matt Biilmann: I think about it a bit more abstractly. Of course all of those are techniques to build a great agent experience. But in the core of it, it’s a holistic experience that an agent has of your product. And holistic in the sense that it covers everything: the documentation, your website, your signup flow, everything. And I’ve been thinking in four specific pillars that are useful to us. The first one is access — just, how can an agent get access to your product? That’s kind of the first stumbling block, and it covers the onboarding and everything. How does it know to get access, and how can it get access? Does it need permission from a human? Can it start building without permission? How does that work? There’s still so much to be built and discovered there. We came up with this thing of “deploy anonymously and claim later” that I think has spread a lot over the industry — this way of giving them a sandbox and then later having a way for the user to claim it. And that’s definitely a strong starting point. But it’s also clear that we probably need different ways for agents that are doing stuff on behalf of a human to be able to identify themselves. Auth0 have things they’re working on. Coinbase and Cloudflare just launched one path there. But it’s still sort of an open question — how’s that gonna work? Access and authorization is a really big part of the agent experience, because it’s the onboarding of: how does an agent even get access? The next big pillar for me is context — which is everything that goes into context engineering. Because in the end, an agent is a simple loop. At the very core of it, it’s just a loop with LLM calls and tool calls, and inside that loop, for every LLM call, there’s a context. And what’s in that context typically determines how well the agent is gonna use your tool, your product. It determines whether it knows your product exists at all. And it determines a lot about whether it knows how to use your product. And inside that context discipline, that’s where you will have all the changes people should make to their doc sites to make them agent-friendly. All of the work we do to make everything now copy-pasteable and markdown everywhere — because the human needs to be able to feed it into context. It’s a core part of MCP. Which I think a lot of people got really disappointed about, because they thought about it as something that — it wasn’t a replacement for APIs or something like that. But the one thing that’s interesting with MCP is that it kind of gives you one place to build a UI for agents. And that UI is context. It’s a model context protocol. It’s basically a protocol for getting context into that inner loop of an agent. And that’s where it kind of like the most interesting use of it is. But there’s context engineering and CLI tools. We all started thinking about, how does each of our CLI tools look like for an agent? How do the errors and responses and all of those look for an agent? Skills, custom context files, and all of these things. So context is a really big part of the agent experience, because in the end context is how agents understand your product, or don’t understand your product. And then the third pillar is the tools themselves. Agents are gonna try to use your product, and they’re gonna use them through tools, and sometimes they’re gonna use them through tools you don’t control. If you don’t have any tools, agents might use computer use, or just their Chrome extension to run the browser. So one thing I think is important is that any product has an agent experience, because agents will try to do stuff with it — it’s only a question of whether it’s a good experience. And that also comes down to how much are you building tools for those agents. CLIs have become really crucial. The APIs themselves are really important. The level of documentation around those APIs. SDKs can become really important. Again, there’s some overlap with skills and MCP that also feeds into the tool category. But this whole discipline of how do we need to build those tools for agents is important. And then the last pillar I think is really orchestration. Where one thing is that agents come to your product from the outside — access your product. But you’ll also start seeing more and more: how can we make it easy to kick off the agents from your product? How can we feed the other way? Like Linear has done an amazing job on that, and I think it’s really interesting to see. Generally it’s interesting to look at companies that have done a great job of AX and a poor job of AX. Linear, definitely really great. Orchestration was one of the areas where they were really early — to make it super simple to go from a Linear ticket and tell any of these coding agents, “go work on this ticket.” And they just launched an integration of our Agent Runners as well — similar, just kick off an Agent Run on Netlify. But it’s a good example compared to, for example, Asana in the same space. They very early came and built all of their own agents inside Asana. And long term, I think people don’t want all these random agents from random SaaS companies. If someone works with Claude Code, they don’t want the coding task to go to some random one. If someone has their own Claude Code that’s fully configured and they invested so much in building their own agent stack, then they probably don’t want some other random agents running their stuff. So figuring out how we can orchestrate people’s agents I think is gonna be really important for having a really great agent experience. The loop doesn’t just go agent to your product, but also product to those agents.
[00:36:48] Victoria Melnikova: I mean, there’s so much. I feel like this topic is just so rich — my mind starts to wander, like, oh, maybe Asana is not a developer tool, you know? So people will be struggling to figure out their own Claude, and maybe they do need an agent. But you’re absolutely right that we have to resolve for all of those scenarios.
[00:37:10] Matt Biilmann: Yeah.
[00:37:11] Victoria Melnikova: Who are your target users? You have to understand that.
[00:37:13] Matt Biilmann: And I think it’s more a question of: are you giving a broad surface area for letting agents work with your product and letting your product work with agents, or are you trying to create more of a walled garden? You see a lot of traditional SaaS companies trying to create that wall, where they can control the agents — because obviously on paper it’s a better monetization strategy. But the problem is that you’ll start seeing people pull their data out of those products to be able to have their own agents work with them. And then they start building more and more with data outside of those products, and at some point they’re all gonna be like, “Hey, why are we even sending it into that product in the first place?” And we are seeing that happening with a bunch of tools right now.
[00:38:07] Victoria Melnikova: This is very interesting. I also see a lot of — you know how in 2025, especially the second half of 2025 and early 2026, there was a lot of enthusiasm and excitement about agentic workflows and people were just really eager to try it. And now I see more of a pragmatic approach, when people actually see a lot of agentic code in production, and they start to have opinions about, “oh, maybe it’s overcomplicated” or “it’s actually hard to monitor — I have to watch my agent all the time, and now I have to do all of those manual reviews of that code.” Where do you think we’ll arrive by the end of, let’s say, 2026, considering how fast things are evolving?
[00:38:56] Matt Biilmann: No matter what, if you see the broader picture from 2022 till now — the overall evolution of LLMs and their ability to do tasks like writing code — I don’t see any reason to think that there’s any end to that level of improvement. There’s a lot of things happening where there’s constantly a level of hype where people get so excited about what they can do fast that they ignore the frailties and the things that just don’t work. I think you see it a lot — like, I think for example right now there’s a lot of excitement around code factories.
[00:39:48] Victoria Melnikova: Mm-hmm.
[00:39:49] Matt Biilmann: And my view there is that I actually think the excitement is real, in the same way that people were excited about autonomous coding agents in the beginning of 2024. And you could point to all the output of those and say it’s just not very good. And I think right now with code factories we’re kind of in that state. They’re really exciting, but if you really try to do it, it’s probably not that good. And you’re not really seeing a lot of companies that post about code factories that are also just like scaling in terms of the amount of product they’re building. That’s good product. But at the same time, I think the current world where it’s still developers that sit and read all the code and verify that it’s good code, it’s a temporary state of the world. And the end of that temporary state is not going to be back to developers writing all the code by hand instead of reviewing machine-generated code. The end of that state is gonna be developers no longer reading the code. So a lot of the tooling and instrumentation and techniques around validation instead of code review that people are experimenting with now and trying to figure out — it’s too early for production use cases now. But a year from now, we’re probably gonna start seeing that approach starting to produce real production use cases. And then there’ll be this shift where, if that flywheel — the moment that flywheel starts working for real-world use cases — it might work, and it might not even be faster than a developer team using agents in code review. But it will accelerate. Whereas the developer team using code agents will not accelerate at the same pace. So I think that’s why you’re seeing a lot of discrepancies between the hype of stuff that gets people incredibly excited and are yet not actually ready for production. There will come some point where it suddenly starts working for real things. And that point will be pretty dramatic in terms of how we build and operate software. The timeline is always hard to predict. But I just think it’s very easy to miss just how wild the evolution of these LLMs in their ability to write code has been over the last two years. And I think we are just at the early beginnings of that, and not at all at any kind of end state.
[00:42:36] Victoria Melnikova: For a company like Netlify, is it scary, or do you think that the future is bright? When you think about how Netlify is gonna fit into that new landscape where LLMs are that good and they can write production code with very minimal to zero human review?
[00:42:53] Matt Biilmann: For us, I think it’s an incredibly exciting time. I think until the end of last year, our total addressable audience was realistically around 17 million professional JavaScript developers. That was sort of our actual addressable market of people. This change means that now our actual addressable market of people is more like the 3 billion people that are technical enough to use spreadsheets and have internet connection and technology access and so on. That expansion of our TAM can’t be anything but incredibly exciting. I think we are in the midst of this massive shift from buying to building software. And we are in the midst of this new world of computer literacy, including the ability to build software, which it never did before. And I think we are in this early stage where people who are not developers, who learn to build software, will have a real competitive advantage in the market. If you are a marketer and you can use coding agents to solve large parts of your job through software, you’re gonna be much higher market value right now than a marketer that can’t. I also think — that’s like the starting point. Some years from now, that will be an expectation of anyone. If you can’t build software, then why would I hire you? Similar to when computers came along — being computer literate in the nineties was a massive competitive advantage in the job market. And then in the two thousands, if you were not computer literate, it’s a real problem. I think that’ll be the same journey for us. It’s really exciting because I’ve always sort of been in the business of helping more people build on the web. And nothing has ever compared to this expansion. An old friend of mine, childhood friend and neighbor — he’s a chiropractor, and he’s just now opening a new clinic, and he just sent me a link and said, “look, I built my new website with Netlify.” It’s like — he would just never have been a user of my product before. And it’s amazing to see. And I think when you build this amount of software, you’re gonna want pretty opinionated platform and infrastructure layers to run them on, that have zero operations. Because when the amount of software goes up so dramatically, if the amount of operations also goes up, that becomes untenable. Even if you start applying tons of tokens to operate your stuff, it’ll be a lot more efficient if you don’t have to. And that’s always where we’ve been sitting in the landscape. So we are really excited about that potential. And we also — we launched this product called Agent Runners Spec last year. That essentially takes what we see as the strongest long-term bet on coding agents — the CLI-based coding agents from the frontier labs themselves. So Claude Code, Codex CLI, Gemini CLI. There’ll be a lot of others, but I think those are just kind of going to be the standard, because when you own both the model training and the code harness and you can do reinforcement learning across the tool, it’s gonna be very hard for anyone that doesn’t own a frontier model to compete in terms of how those agents can work. And we built Agent Runners to make it possible for people to just prompt agent runs with any of those three directly from Netlify. We built our own sandboxing infrastructure to spin them up, have them work on your projects, and tie them into our traditional deploy preview workflow and so on. And tomorrow — I can say this because I’m sure this will be sent after the news — yeah, it’s gonna be in a couple of weeks. So tomorrow, from the day where we are recording, we are gonna launch what we call “Start from Agent Runners”, where you will now be able to go straight to Netlify and prompt a new project into being, directly with Claude Code, without ever leaving Netlify.
[00:47:24] Victoria Melnikova: Wow.
[00:47:26] Matt Biilmann: And that’s of course our first step into being a full end-to-end platform for building. But also in our open nature of being an open platform with all of these well-documented core primitives, built on agents that are the same. It’s not like a weird Netlify agent — it’s just Claude Code. It will use, like, if you add skills and everything, it’ll use it the same way as locally. And you’ll still be able to get the same repo and work locally and push and so on. It’s not a closed-off black box. But it is also a start of orchestrating all of these agents to do work — both when you prompt them and in the future maybe when you don’t. There’s so much opportunity in saying, “Hey, we sit in this whole stack. We can see that there’s starting to be error rates on a function. Can we have Claude Code go and take a look and give you a deploy preview with a potential fix?” There’s so much we can do in the space where we sit between infrastructure and workflow and agent orchestration. I think we have a really unique opportunity. And then the most interesting challenge, I will say, is changing our user experience to this new world of developers that are now much more varied. Where before, even if we had beginners and principals inside that 17 million JavaScript developer box, they were still a lot more similar than the spectrum of 3 billion people, where some of them are really traditional hardcore developers with full knowledge of everything, and some of them are chiropractors. So rethinking our user experience in a way where we can meet that whole team in the future — without talking down to anyone — probably focusing more on the outcomes than the technicalities. That’s one of the really interesting challenges for a traditional developer tool like us, but also really exciting.
[00:49:45] Victoria Melnikova: So I guess it stopped being a developer tool per se, and it’s gonna be just a builder tool.
[00:49:50] Matt Biilmann: I think about it differently, because I think we are gonna see all of these people become developers. And I think the ones we wanna serve — there’ll be other tools than us that are better at the very surface, like if you really just care about the outcome and so on. I think even the current generation, Lovable and Bolt and so on, there’ll probably be tools that are even more consumer-like than those. I think we still haven’t seen the YouTube for software. And I’m sure we’ll see stuff like that, that becomes really for people that definitely don’t see themselves as developers. I still think we are gonna sit a little more in the space where people are actually doing this for professional reasons mainly, and they’re probably working on business properties and so on. But where we are just gonna go from a world where a developer was a very binary thing — where you’re sort of really either one of the few developers or you are not — similar to what the printing press did. Before the printing press, reading and writing was a very binary specific skillset. You would have professionals that were scribes — only their professional skill was reading and writing letters. Obviously today we’re in a completely different place. You can’t get a job by being a scribe — that’s not gonna happen. But there’s probably way more professional writers than there were in the medieval ages. Also, just about anybody is expected to be able to write as part of their job. It’s no longer a binary skillset where you’re either a writer or you’re not. It’s like, yeah, of course you can write. Doesn’t mean that we don’t have dedicated specialists that are amazing writers, and we have like normal business-level writers. And I think development is gonna be the same. Of course you can develop some software — like otherwise, what are you doing as a marketer? But of course there’s also still gonna be things where you need really skilled developers that fully understand software architecture and all of that. And I think those teams will be working together. We are already seeing that internally. Our HR team is building a lot of software now. And they can do most of it themselves, and then sometimes one of our developers needs to step in, help them unblock something, help get data access, review a security pattern or something like that. And then they can go build. And I think that’s gonna be the future. It’s gonna be much more varied teams — some that are exclusively developers and some that are developers plus something else.
[00:52:35] Victoria Melnikova: I mean, it sounds exciting, and I’m one of those people, you know? Because I can already use Claude Code with Zed and do things that I was never able to do before. So it’s very close. It feels like we can touch it already.
[00:52:49] Matt Biilmann: Totally. Totally. And I see that happen. I mean, we see that all over Netlify. Like our AEs are writing custom maps for their proposals. Our CFO internally in the company is the highest credit spender on Agent Runners. He’s been building all kinds of finance dashboards by hand. Our support teams are building chunks of tooling to help them bulk-resolve issues for customers. And I think it’s not something abstract for me — I’m very much seeing it in action, and seeing it in the uses of the platform we have now.
[00:53:37] Victoria Melnikova: Yeah. So you are the CEO of Netlify. Do you ever envision giving up that title? Like, does it ever get tiring for you, or are you just that excited builder still?
[00:53:50] Matt Biilmann: I mean, right now I couldn’t be more excited. It’s such a fun period right now. Again, when I started Netlify, it was this emerging frontend developer that was seen as sort of a pseudo-developer, and people didn’t really take them seriously. And I really saw an opportunity of bringing them online as the mainstream web developer. And it actually happened. That was the first take of Netlify. This is like being back in the early days again. There’s these billions of people that people are still not really taking seriously as developers. People are still talking about them as just vibe coders and so on. And these are super smart people with tons of domain knowledge. They can have a ton of usage out of software built, not by someone that’s trying to understand their field, but just by themselves. Having a chance to play a role in bringing all of those online as developers that can build on the web — that’s very exciting to me. And I definitely don’t feel tired. I’m definitely ready for another 10 years.
[00:55:07] Victoria Melnikova: So this brings us to my final question, which is always the same for every guest. It’s called Warm Fuzzies, and it sounds like this: what makes you feel great about what you’re doing today?
[00:55:18] Matt Biilmann: Seeing people build stuff with Netlify — that’s like the core of it. I see a lot of it, and we have this internal “share cool stuff our customers built” channel where we just post links to stuff like, “oh, this is on Netlify.” That is still the number one thing that gets me excited — when I see someone build something cool with what I build. And then just being in the middle of the biggest shift in technology since the web itself, and having an opportunity to play a real role and shape it. Because it’s not a given — any of these shifts will have things that we end up feeling are bad and things that we end up feeling are good. And they all have potential to dehumanize or intermediate, and they all have potential to increase the potential for human creativity and reach and so on. And it’s not some distant given path of where we end up in those scenarios. So having an opportunity to actually try to humanize this and build a platform where humans can create amazing things, where humans can be builders, can share with each other and reach each other — that’s what makes it fun.
[00:56:40] Victoria Melnikova: Actually, evilmartians.com runs on Netlify.
[00:56:43] Matt Biilmann: Awesome, awesome.
[00:56:45] Victoria Melnikova: We’re gonna — I’m gonna send you a new website that we’re working on. It’s quite fun.
[00:56:48] Matt Biilmann: That’s the kind of stuff I’m looking forward to seeing.
[00:56:53] Victoria Melnikova: Thank you so much, Matt. It was a pleasure talking to you, and I’m sure people are just gonna be in awe listening to, first of all, your energy and how excited you are about AI and what’s coming, but also just learning insights that might not be very clear to people outside of the bubble, because we’re in SF and it feels very condensed here. And I’m really hopeful that this information reaches a wider audience.
[00:57:20] Matt Biilmann: Thank you.
[00:57:21] Victoria Melnikova: Thank you so much, Matt.
[00:57:22] Matt Biilmann: Thanks.
[00:57:24] Victoria Melnikova: Thank you for catching yet another episode of Dev Propulsion Labs. We at Evil Martians transform growth-stage startups into unicorns, build developer tools, and create open source products. If your developer tool needs help with product design, development, or SRE, visit evilmartians.com/devtools. See you in the next.
