Bootstrapping Netlify to a multi-million-dollar company
We also talk about:
- how he got the vision for the JAM-stack,
- how it feels to grow a company from a two-person adventure to over 150 employees,
- how he envisions the collaborative software development of the future,
- and the acquisition of FeaturePeek.
Career at Netlify
Other episodes you'll enjoy
Read the whole episode (Transcript):
Michaela: [00:00:00] Hello, and welcome to the Software Engineering Unlocked podcast. I'm your host, Dr. McKayla, and today I have the pleasure to talk to Matt Biilmann. The CEO and co-founder of Netlify.
But before I start, I want to tell you more about CodeSubmit - the best take-home assignment platform to streamline your tech recruiting! Yes, exactly. This amazing start-up is back sponsoring the podcast. And over the last month, they introduced a lot of new exciting features such as live coding with the full working IDE running directly in your browser. CodeSubmit makes it really easy to recruit and hire amazing tech talent. They support 64 different languages and frameworks, and integrate seamlessly with git. Beginning of the year, when I was hiring engineers for a start-up, I used their tool during the interview process for all the candidates and I was extremely satisfied. Their mission: real tasks, not brainteasers, resonates a lot with me. So, I cannot recommend CodeSubmit enough. Please check them out at codesubmit.io. That is codesubmit.io.
Matt: [00:01:50] Thank you for having me.
Michaela: [00:01:51] Yeah, I'm really really excited. So how is that? I looked a little bit like a research to you obviously a little bit. And so I saw that it's around, you know, seven, eight years ago that you, that you created or you founded Netlify. How was that? Is that, was that you have an idea and you do it, or what was the process like?
Michaela: [00:12:16] Yeah. Yeah. Mind blowing. Wow. Yeah. It's mind blowing. Yeah. And so for me this, you were really very very involved with the technology and you had like this vision where it's going to go and it also went there, right? So it was like spot on. Do you feel like that you're still very connected to that? Like, do you still feel like that you're so connected to technology or are you now more involved in, you know, you have to see overall? I am now a little bit more away from this technology side? And how is that for you? You've, for me now, how you explained it and how much passion I could really see that, right? I can imagine that you have also like this passion for the role that you have right now. So you're probably extremely business oriented and you know, all these funds and you know, like where to raise money and how to acquire a company and all of that. Are you still very technical? Do you feel like you're as technical as you have been before?
Matt: [00:13:16] I'm obviously not as involved in building Netlify from writing code perspective like as I was, right? Like the first version of Netlify I built a CDN from the ground up and the CI/CD platform and the React UI that powered it and everything, right? Like, and now I typically don't like my working stage now doesn't involve writing code file product, right? But a curious thing about my background is that while I've been programming as a hobby since I was 10 years old, I studied the musicology and cultural studies and was always more interested in how humans adopt ideas and make sense of the world and understand things. So I think some people are need to feel very hands-on with the code to feel that they are doing something. I get a lot of joy also out of building the culture and the organization and the engine that can build things without me, right? And trying to understand both how, when we talk about something like the JAMstack emerging for example, and the shifts in technology. There's always a mixture happening of like the actual sets of technologies involved and the specific program languages, and APIs, and infrastructure evolutions that we're seeing. But in the end, technology are, is adopted by humans learning about things and building things, right? And you can understand where technology is going, what will happen in an ecosystem? If you don't understand how humans adopt technology and why developers built with certain technologies at certain points in time and why you'll sometimes see technologies that are technically better loose out in the marketplace because their adoption path is harder, right? So for me, it, I've always been a very curious person and like to understand both sides of that spectrum, both the lower details of how does technology, like how does that technology work behind the scenes, but also the details of like, how does human beings approach it, and understand it, and build with it. And of course, as I've been building this company, and as I am building it, the layer of where I operate, they are all have to keep shifting, right? Like in the beginning, I had to be the one who just sat down and wrote the code. And then I had to be part of a team that wrote the code. And then I had to be more of a take lead for that team and guide them in the right direction and so on. And now I have to build the right kind of organization and the right kind of organizational structure to allow our company to build the kind of product that we think we need to build. And that's in some cases also like requires finding the right partners to build it with in terms of investors, or ecosystem partners, or finding the right people to join our team and help build it.
Michaela: [00:17:01] So, this is really really super interesting. Is it for you all about the people or is it also about the structures and how people are working together? Do you see it as a system? Or, you know, like, or is it self-forming, like is the company self-forming or do you give it some structure?
Matt: [00:17:20] No. No, we, you, I believe in trying to bring some structure along the way. I think both me and Chris have always thought that intentionally building structure and organization is really important for building a company that can scale to become a really large company, right? Like I think, if you try to ignore the structure, you will hit a point where everything starts falling apart. And it's very easy to hit points along the way (laugh) that feels like that's happening. Of course, you're always a bit riding on a rocket that's slightly out of control, right? But I think culture and structure and values are really important for how a company functions. And then of course, like you can never replace the, like, it's in the end, it comes down to actual people doing stuff, right? But the structure is important and it's important to be intentional about it. I think we've seen some companies that tries to build completely like say they built completely flat structures without in any kind of structure to it. And that just means that as a leader, you're not taking any intentional decisions around the structure because your team is still gonna have people that have more facility (??) than other people. And they're still gonna have, it's just gonna happen by politics and sort of maneuvering rather than by any intentional process of like how should the structure be.
Michaela: [00:18:41] Do you see like a parallel between like architecture, like software architecture and technical debt and structures of companies like where you say, well, we try to build the best system with the information that we have right now. Obviously also looking into the future, but then, you know, things evolve, things change, so we actually have to go back and change the architecture or change, reverse some decisions, you know? Remove some technical debt? Do you see the same happens in company, in your company structure? Or do you feel like, oh, this is for what we have foreseen, but now we actually have to restructure and refined or redefine ourselves?
Matt: [00:19:23] Yeah. You absolutely see that happening. And of course it could be a useful metaphor to compare like your company through to the machine, building the thing and think of it as an architecture in that point. Just also have to remember that in the end, the pieces of the machine, so not lines of codes, that are predictable. They are people with goals and dreams and carrier ambitions and interpersonal characteristics. So you have to be aware of both sides of it.
Michaela: [00:19:59] So you're what you're saying is that technical debt is sort of peanuts, right? (laugh) That complicated for you, right?
Matt: [00:20:14] I just, it's a lot easier to deal with technology. It's a lot more predictable in the end than people are. But in the same way, it can also be a lot more fun to deal with human beings.
Michaela: [00:20:21] Yeah, obviously. Yeah. Yeah. I'm super impressed. Like I can't imagine how much personal growth has to happen on a way from, you know, like bootstrapping something, then getting investors, you know, scaling, probably if you get investors, you normally scale really fast, really quickly. And yeah. So that sounds super awesome.
Matt: [00:20:45] Yeah. And it's also, I mean, it's also a choice you take when you go and raise venture capital that, raising venture capital is only one way of building a business, right? Like the many other approaches to build a business. In our case, we felt that there was also the kind of market opportunity, right? Because we really, from the get-go belief that there was a real opportunity to shape how the future of the web is going to be built and how it's going to function. But we could also see that making that big of an impact and getting there in time and so on. There was not something we could have done if we had grown just organically based on our revenue, right? Like, so that's why we went out and raised funds to be able to scale and grow much faster than we would be able to do organically, right? And that, of course always didn't have the trade-off of like all the challenges you get when you are trying to scale an organization very fast. And it has like, you have to know what you're going into as a founder also, right? Like, it's, of course, it's a learning curve and you have to be very okay with continuously taking things that you saw as core to your role, like writing the code, building the technology. And then have other people come in and do them instead of you and step away from it, right? But if you do that, you'll also learn very quickly along the way that the more like, that no matter how much of your job you seem to delegate it away, you only get more busy somehow. (laugh)
Michaela: [00:22:31] (laugh) Yeah. Yeah. So one thing that would really interested me is like you said, you wrote this little first version MVP of Netlify. And a lot of people adopted it. So it seems like you didn't really have to convince people about this solution or that there is a problem because sometimes like founders, it's hard, right? You think like, oh, I have this idea, and then, is it too early? Do I have to convince people to have to explain it better? Do you have like to, do you think that this is the right mindset or should people step away from something like where we have to tweak one sentence to be really powerful and express like the pitch, right? Is that really so important? Or should we read our focus, our energy on finding the thing that people actually want even if you write a sloppy (laugh) sentence about it, you know what I mean? (laugh)
Michaela: [00:30:08] Yeah. The funny thing is that when you described the story of, you know, how a developer, you know, sees your side and tries it out. This is exactly how I felt when I tried it out. I was not an early adopter though, right. I tried it out somewhere last year, but, it wasn't exactly like this. It was like, oh, I have to deploy this website. And I want to do it quick. And you know, like, let's try that out, right? Everybody is already on it. I'm like the late late person (laugh) too late for everything. But I went to it, right? And obviously at that point it was fully baked, right? Fully in, but, you know, I was there and was like, wow. Well, it's running, right? Like I was like, and as you said, right? This is like you push and then it's there. I exactly felt what you were saying, but it was like last year. How was Netlify when you say, well, let's go five years back. How was the experience? Was it similar? Like at that point, would you say it was similar?
Matt: [00:31:10] Yeah. So, the expense involved in, and it will continue
evolve as we also go for, broadening the experience and telling it different,
like as a large and larger story through the product, right? So the very first
story you would see was in BitBalloon, the predecessor to Netlify where you would
land on a website that just immediately on the front page head (??), like a drop
zone saying drag your web folder here. And there would also be a little download
link where if you didn't have a website handy, you could download one and drop
it there, right? And then you could just drop aside onto bitballoon.com without
even signing up or anything.
And it, you didn't need to zip the files first or anything.
You just drag the actual folder onto a bitballoon.com, and boom. Now you would
be live. We still have that on, if you go to app.netlify.com/drop, you'll get
the same kind of experience that mimics, like what the very first version was
like, of course, designed by me and not by actual designers (laugh), like it
looks like today. So that was like the first simplest motion we could do, right?
And then, the next step was really to start, like after we had, after I had built
out that initial version of just getting a site live and getting a custom domain
connected to it, getting SSL set up and so on.
Then it was really the question of okay, this is fine if you're really just one developer. By yourself. Manually deploying. And we added a CLI where you could do the same from like writing, at first BitBalloon, and then later just Netlify deploy, and immediately from the command line deploy a folder, right? That's fine if you're really just one individual working. As soon as you're at team of people, that's not very useful. Like you can't just random, you have people deploy manually at different time without structure around. And people get their structure from GitHub or GitLab or Bitbucket. That's where developers collaborate on opening new pull requests and building new features. So. The next iteration of that on Netlify was really saying, instead of focusing on you deploying manually from a folder that solves the whole into problem of you working in a git provider and getting that live. So the next moment really became that flow of like coming. Tell us your git repository and we'll try to even guess what tool or framework you're using, and just say, okay, and now you're done, right? Like now you have something you live. And now of course, with, without acquisition of FeaturePeek and that whole journey, we are going even deeper into that space of like, this is not just for single developer building on their own. Like real projects always built by teams with lots of different stakeholders and with several developers and one part of the processes is writing the code. But another part of that whole process is that for every release, you have some feedback cycle where you have back and forth with product managers, or designers, or other developers, or other stakeholders before you take something live. And now we're really sort of expanding that whole experience to include that process and to show how frictionless we can make. The process of a team actually building releases together and taking them to the world.
Michaela: [00:35:12] So with this acquisition, somehow you have like this deploy previews feature. You know, my favorite thing are code reviews. Is that something that you think is part of the programming part or is it part of deploy? Is it part of something that should be, should code reviews be somewhere in that picture or how do you see that?
Matt: [00:34:36] I mean, code reviews are really important, but then there's also the step ahead that's like viewing the outcome of your current code, right? Like being able to just open a pull request and having that pull request running in the full production environment exactly as it would look like if you merge, that's really like, it doesn't replace the code review, right? Like the developers should still work on the code review tools to make sure that the quality of the code behind that is up to scratch and so on, right? But it does make the preview, especially from QA testers, product managers to designers and marketeers to content editors or anyone else that's involved that will want a preview what the output looks like. It makes that process in much simpler, right? And what we were seeing, like we've, we launched deploy previews in 2016, a long time ago, and we've of course been very big consumers of that whole workflow internally, ever since then app.netlify.com runs on Netlify, all of our web properties up and run on Netlify and that process of deploy preview is completely essential to how our web teams work. We're constantly sharing URLs and so on. But the one thing we saw also when talking to clients and so on, was that when you share that URL, then the feedback cycle spec to the developers that happens all over the place. Some of it happens you're shared in Slack and there's feedback in Slack and or people open issues in GitHub or in JIRA, or they will paste the screenshots into documents and send them back and forth for, add the message attachments, and for developers like the process of that is as fragmented as the process of code reviews was before tools like GitHub and GitLab integrated into the workflow, right? Like before that happened, like there was no, that you, you would've sometimes have specific tools for code review, but mostly it would be processes of sending back and forth emails around the code, or simply just having to sit down at a laptop together, or at this top back of the time, and look at the code and talk through it, right? And GitHub with the pull request functionality really gave that home for code reviews, right? Like in the game of place where now you no longer have to wonder, like where is it happening? And people commenting in all kind of places and so on, right? So, what we're trying to do with collaborative deploy previews is in a similar way to give it a home for the feedback, not on the, on the input, which is the code, but on the output, which is the result. And make sure also that since every deployed preview is a different URL, we don't, we didn't want to have a system where every deploy preview now has its own, like, you have to know it exists and go there and look at the feedback in order to take part in that process because like, we had some initial prototypes integrating with tools like that, and it just attracted from the process because now developers apart from checking the pull request to end a Slack messages and their emails also had to continuously try to figure out is people, are people now also commenting on the deployed preview URL. So it's really important to make each deploy preview URL at checkpoint that makes information flow into their original places. So feedback that stakeholders make on the deploy preview will flow back into the pull requests. They'll take part in the comments there, or they can open tickets in whatever project tracking software you're using relate to GitHub or linear Clubhouse or the like. And that was really important for us, right? But again, was this sense of like, now when a developer shares that deployed preview URL, they are also sharing how to give feedback and how that whole process operates. And we hope that can really, as I said, due for this process, what pull requests themself fit for the code review process.
Michaela: [00:40:13] So, FeaturePeek, which basically is part of what you're just describing, right? Of the functionality that you're describing. As I understand it. Is it company that you acquired? So I would like to understand the process around that a little bit. So you have this vision, obviously. You seem very vision driven, right? So, you have this vision and then you see that there is no place for that. But how does that work? Like, and then you find a company or, you know, like it, because you're, you're obviously having your eyes out on the space and on the companies, and then you see a company that works in that space and you think, oh, they're going to the right direction. And then you contact them. Or how does that, like how, how can that be such a good match and why not do that in-house, and you know, like how does this whole process wig? And what's your, what's your mental model behind that?
Matt: [00:41:03] Yeah, let me, let me tell those. So let me take a step first back and just to listeners share, like yesterday, we announced a big feature for us called collaborative deploy previews that allow other stakeholders to give feedback in the process of reusing and going from pull requests to release. And behind that feature launch was an acquisition of a venture funded company called FeaturePeek that was backed by Y Combinator and Matrix Venture in that joint Netlify and integrated that product into the core of our product. And the whole process started in a way back in our all-hands meeting at the very start of 2020, where Marissa was a UX researcher on our team brought up the initial idea that it would really add so much value to the other stakeholders if there was a way of bringing feedback and commenting to deploy previews. And based on that, we started at first prototyping with a couple of different tools that already existed in the space for commenting and annotating on websites, so we integrated one of those tools through it, built plugin and started testing it out internally. And we learnt there that if the commenting was something external to the current process, our developers got more frustrated than helped by it. Like they quickly felt like, okay, now I'm just getting a part from all the mails and Slack messages, administer git, I'm also now getting comments in a different place, right? So after testing that for a while, we found out that, okay, that's not going to be the right approach. It's the right idea, it's the right problem we are tackling, but it's not the right solution. So we figured that we would have to do something that tied into the process that developers will already working in and that tied into the pull request process. And we did start in building our own, we built first a quick prototype that our developers experienced team built, to be able to take that to our user researcher and then put it in front of a bunch of our clients talk through like, what would this do for their workflow? What are they currently doing for their workflow? And started all to really understanding like the set of tools that our customers were working with and how they were already solving this problem. Because obviously like, it's not like, this is something that everybody are already doing in some way. No one are building software just by having developers write the code and then launch it, right? Like there's always a process of write the code, show the output, talk through it, do testing, validate the result, give feedback, iterate on it, and then you launch it, right? But often that process is just a lot of screenshots and PowerPoints and emails and Slack messages and so on. And we could see that if we could make that flow back into the pull requests that would help, but it wouldn't be enough like when we tried just that with our first prototype, we saw like just pull requests, comments, is not enough. Like people are also using issue trackers and project management software. And we had to figure out how can we integrate into those pieces as well? So this was a long process and we built several internal prototypes and did some, kicked off some real development. And in the process we kept looking at, in any company, they was trying to tackle list in the market. And one of them that started to really stand out was FeaturePeek. So we reached out to them and asked to meet. And they came to us and had at the time actually started working on it, on a Netlify integration through our built plugins layer, and yeah. I was in a call together with Jessica, one of our product managers with the two founders of FeaturePeek. They gave us a demo of what they had been working on in the integration. And as the demo progressed, I would say like our chores got closer and closer to the flow of because it was really far ahead of anything else within this space. And more than that, it was as if they had been reading all of our user research (laugh), like building exactly the kind of product that we wanted to build in and that we were dreaming about, right? So we very quickly figured out that between us and the FeaturePeek founders, we really shared a vision of like, what can you do in this space? And what can you build in? They had already built a product that get a lot of that, but we could also like just talking through future potential. We could see there we were so aligned in like, what could this turn into? And as we started to talk more, it was also pretty obvious that they could build a great integration on top of Netlify and use our integration layer for that. But it would still just be an add-on. It would still just feel like something you could add and that would be bolted on, right? It would have its own, like, separate sort of dashboard, and login, and the integrations would be only on there and not on our end, and so on. That would not really be a good way to integrate the whole feedback cycle as a first-class citizen throughout our whole product journey. It would be feeling like just a plugin, just an add-on, right? And we felt between all of us, that if we really wanted to do this integration had to be much deeper, had to be much tighter. And we would only really be able to do that if we were one company. So then we started talking about what if we join forces? What if we, what if we built something together, then build something into different silos? And ended up agreeing that that was the right way to go.
Michaela: [00:47:26] And so now, you acquired them this week? And are you going to develop something now or is it already developed? Or, you know, like how does that process would like?
Matt: [00:47:38] So, we did the acquisition in about three months ago and behind the scenes that their whole team and our team have been working really hard on integrating their technology really deeply into Netlify. So Netly, so yesterday we didn't just announce the acquisition. We also announced the full product launch with all of these collaborative features now available to all Netlify users from yesterday on.
Michaela: [00:48:09] Very cool. Very cool. So you took the code base that they had, and then it, it's not a complete rewrite, it's just that you plugged in what they had, you know, got rid of some, you know, functionality because it was a plugin first and now it's, you know, it's part of Netlify. So you, took the part of the code base and integrated it? Or how does that work?
Matt: [00:48:33] The team that has like they both whom rewrote parts of their code base to integrate it into our code base directly for the whole co-API functionality. I think our team together with their team built three new micro-services to power like identity for cross integrations, for uploads and so on. And they updated the whole UI to be in line with how we built Netlify's UI and to feel integrated into that process. But I have to say was like an incredible job from the whole team, executing that in just three months and taking it to market.
Michaela: [00:49:20] Yeah, I can imagine. Yeah. Yeah. Well, it did. So I have 1000 more questions, but we are on time. So (laugh) I will just, I would just say thank you so much for sharing everything with me and with our, you know, with the listeners and with us. It's like, yeah. As I said, I just have so many more questions. I could talk for hours, but you maybe I'm inviting you again. Maybe you have time to spend a little bit more talking with me about all of those things and I can give you more questions. But yeah, it's, I'm really impressed. It's a, it sounds really fascinating and really cool. Is there something from your side that you want to share, like with my listeners that you want to give them on the way I will obviously link everything in the show notes, but is there something that you want, especially for people that are, you know, like love technology, software engineering, and also maybe want to become founders or, you know, do their own thing?
Matt: [00:50:20] Yeah. I mean the first thing I would say, if you think all of this sounds interesting and you would like to be part of it, we are very actively hiring. So check out our careers page and if you don't find anyone, anything there but think you could be a great part, then we always have your dream job position that you can write in for, so that would be the first part. And the other part, I would say is that as this whole shift from big monolithic applications having to modern architecture with it, decoupled frontend and all these different APIs and services. There's also a lot of opportunity for founders to build new interest, new interesting pieces that fits into that developer workflow. And I'm always happy to spend time with founders in that space that are building something new or interesting. So, feel free to reach out or Twitter or email or the like.
Michaela: [00:51:25] Wow. That sounds really nice. Cool. Thank you so much, Matt. For being on my show. It was really a pleasure. Byebye.
Matt: [00:51:45] Thank you for having me. Bye.
Michaela: [00:51:37] I hope you enjoy the another episode of the Soft Engineering Unlocked podcast. Don't forget to subscribe and I talk to you again in two weeks. Bye.
Copyright 2022 Doctor McKayla