It’s time to go bigger

I think it's fair to say that the way we build software has changed on a fundamental level over the last few years, especially over the last couple months. Many people see this as a threat to our jobs in engineering, but I'm trying to see the other side here. The things that we can create that didn't make sense to create before. And I'm getting really excited when I think about things that way. I've noticed a lot of engineers are realizing the power that these tools have, but haven't really realized what they can do with it yet. And the result is that they feel fear. When you look at the hundreds of hours of work you used to do and see that a lot of that can be done in 15 hours, 10 hours, or sometimes even less, it feels like you don't have much to do anymore. But there is a way to do more. In fact, it's just that, doing more. I want to talk a bit about this though, about how I've been thinking about what I build and how I build it and how much that has changed as a result of the cool AI tools we have to help us building today. Most of this video is going to be based on a talk I gave at CascadiaJS earlier this year, but I want to go a bit deeper with y'all because I think that this is a very helpful framing on where things are at and where they're going, but most importantly on how we can build really cool things using these tools today. This video isn't meant to be about specific tools or technologies. It's meant to be about how we think when we use these things. What do we build and how do we think about what we're building? I really don't want this to be about specific tools, but I will take a quick break for one awesome tool, today's sponsor. I got a weird question for you. Can agents sign up for your app? I don't mean like navigate a form really poorly and ask the user to input stuff. I mean an agent hitting an endpoint and actually registering you to use the app. It would be really nice, wouldn't it, if agents that know how to pick all these nice technologies could pick yours and actually sign up for it. Work OS agrees and that's why they made a new standard OMD. Normally these guys pay me to tell you all about how powerful their enterprise o platform is, but today they're paying me to tell you about an open standard that they help build. Pretty damn cool, right? The point of OMD is to make it way easier for agents to actually register for a service on behalf of their users. The initial partners are companies like Cloudflare and Firecrawl, which means agents can now go sign up for Cloudflare and deploy an app on it for free without you having to do anything. What's even cooler is how well it integrates into work OS's existing platform. They've made it so it's literally one click to enable agents through OffKit, which is super cool. I've seen solutions in the past that allow agents to like do a signin, but I've never seen something like this that allows for agents in user accounts to link in a way that makes sense. And if you don't want agents blindly registering users on your service, you can switch over to a user claimed flow where the agent signs up, but then nothing happens until a user clicks a button to add it to their account. Getting off right was already hard. Getting it right for agents is even more difficult. Do it correctly at soy.link/workos. As I mentioned before, a lot of this is based on a talk I gave at Cascadia. Definitely recommend watching that as well because it'll be quite different from how I overview it all here. But let's go through. It's time to rethink everything. Building software has changed a lot. There's one particular invention that had the biggest impact on how software is thought about, built, and architected. And more importantly, how teams are hired and structured when they build. That technology is obviously the cloud. The cloud fundamentally changed how software is being built. Many of us are not old enough to have been there when that happened. And I was one of those people. I was there kind of at the start of the cloud when I was getting into writing code more seriously. The idea of like renting servers from a company that you would buy groceries from with Amazon was so weird when it happened when I was younger and now it's just the norm. Like if you're not using AWS, you're kind of weird now. The cloud was very important because life before it was much harder. Before we had the cloud, building was really capital intense. If you wanted to add a new service or a new feature to your existing service, you had to predict traffic and you had to predict it really accurately because if you get less traffic than you expect, then you bought too many servers. And if you get more traffic than you expect, your servers crash and die because you have to buy and provision actual machines for all the work you want to do. And with this, as I said, you have to predict the future. You have to know what's going to happen on your service. And if you get it wrong either direction, you're wasting a ton of money. And this means that experimentation was inherently really expensive. It just wasn't worth trying out new ideas if those ideas had such a high risk of even in success kind of failing, but if they didn't succeed, just being expensive. If you have to rack servers to try something new, you're kind of screwed if things don't go how you expect. Now we live in a world postcloud where you can start small and scale up trivially. Just spin up the number of servers resolving your service. Experimentation is cheap as a result because you have so many better tools to try things out to start small and go Amazon scale. And with that, you don't need to hire god tier infrastructure devs anymore just to try out some idea. Amazon tier scale is now available to people building without having to have an Amazon tier team or Amazon tier buying power. What I'm trying to say here is that we've been through this before and just because AI is this crazy thing changing how we build doesn't mean our jobs are going away or that this field is going to die. I argue that it's kind of the opposite. The same way something like AWS made us go from building bespoke internal software for big companies to building new services and solutions. Everything from Slack to Salesforce. Yeah, they acquired each other. It is what it is. You get the idea though. There's so much software that just didn't make sense when you couldn't provision it at scale trivially. And more importantly, you couldn't get these things to a business because they wanted to run it on their own hardware, which wasn't doable before something like AWS made it really easy to just spin up other things in your existing cloud. Enough about the cloud. We need to talk about the cloud now and specifically what life was like before the cloud. Building was capital intense because you needed to hire enough engineers to actually build the things you wanted to put out there and test. You had to predict the future because if you didn't hire enough engineers or you hired too many engineers for the thing you're trying to build, you're kind of screwed. If it turns out your iOS app is way more popular than your Android app and you hired a four-person team for both, what do you do about that? If it turns out people only like the web version and no one's using the mobile apps, what do you do with those engineers? And this is one of the worst parts is that experimentation isn't just expensive. It is, how do I even put this? It it's soul crushing as the person trying to run these experiments. There's nothing worse than hiring people to do something, to build something, and for them to do everything right just to realize the thing that you had them building was wrong, and now they have to have their whole life and career paths changed as a result of your bad judgment. It makes experimentation scary. Even as somebody in a position like mine where I can hire people to help me build the thing, it's so scary to hire them for the wrong thing to build and to deal with the consequences later. I've had to lay off a team before. It sucks. And it makes you hesitant to try new things because the social costs, the life costs, the impact that a layoff has on the people who were there to build the thing just [ __ ] sucks. And that makes you steer away from doing bigger bets because when the bets fail, you're hurting people. But now this has changed. Thanks to all of these cool tools that we now have, you can build Amazon scale software in some ways without having to hire up the same scale of engineering teams to do it. And with that, everything we believe about this industry is no longer true. The fundamental truths we have built our industry on just don't really fit the way things work today. The way that we spec out projects, the way that we do reporting on incidents, the way that we structure our teams and how they are built and how they hire and how they release, all of these things don't make sense in a world where the actual codew writing has gotten so much cheaper. Because of this, it's time for us to start challenging our preconceived notions of what should or shouldn't be built, what does and doesn't work well, what tools should or shouldn't we rely on, and most importantly, what's worth rebuilding or replacing. I actually am going to do a follow-up video about a bunch of those ideas. This is more meant to be a context builder to get you thinking the way that I've been thinking in order for those ideas to make more sense. But I want to give one example of a company that you would never have competed with before because the way things worked before didn't make sense, but now suddenly it would make sense to compete with them. It's actually a company we mentioned before. It's Salesforce. Salesforce is a really powerful product with a shitload of features that is used by pretty much every major company in the world. They have a lot of features. If we were to try and break down their features in a spectrum, you know me and my diagrams, you have a small section of those features that everybody needs. All of their customers rely on these things. Basic stuff like authentication or email notifications. Like everyone relies on that chunk. Then you have another chunk that is real stuff that bigger companies need, but not everyone needs. It's more features than that core piece, but it's a set of features that is smaller than this greater piece. And a common failure mode I see companies falling into is they build all of these features in this section on the left here because everyone needs those assuming that by building that everybody will be able to move over. But then they go talk to the big companies and they need this set of features which is a lot more to build for any one of those companies. And even if you start to land one or two of them, you end up in hell because of the rest here. Less than 1% of companies use any of these features. I would argue that probably 70% of the stuff something like Salesforce does is not used by 99% of the people who use Salesforce. But there's a problem here. If we flip this to instead be what features a company needs, not what features Salesforce has, the ratio looks very different. Vast majority of things a given company needs are those common features that every company needs. But this last section here just has a couple features in it, one or two maybe that a very small number of companies need, but now that they've had it and they use it, they expect it and they're not going to leave and go to a different service unless you specifically build it for them. If you're building a Salesforce alternative and this potential customer has 12 features they need, you already support 10 of them. Doesn't matter how much better those 10 are. If you're missing two, they're not going to come over. Solving this problem required a lot of money, time, and careful design because you would either have to build some complex architecture to allow them to bring in solutions, thereby offloading the work to them, then they have to go do it in order to switch to a product that they don't even know if it's better or not. Not viable. So, what you end up doing instead is hiring up a huge team in trying to build every single one of those features into your application, which is a suicide mission. And you get halfway there, have no customers, run out of money, and die. And I've seen this happen to so many companies trying to challenge the norm because they can't get the feature set that's needed to pull off those customers. The harsh reality is that 95% of the companies using Salesforce probably only need 5% of Salesforce features, but there's a lot of variety in that 5% which makes it really hard to get them as customers. The problem was that you had to build for every one of these special Snowflake companies with their own special needs. Well, you had to. And that's where things have changed. And that's why I'm so excited about where software is going. If you were to think of this as a spectrum where you have the range of different features somebody might want to add to a product, we can use Versella as the example here or AWS even as the example, a cloud provider. On one side here, you might want to have good static hosting for HTML pages. On the other side, you might want deep infrastructure primitives for different database architectures or video encoding or stuff like that. But there's also a vertical depth to this range where in a given section you have to have different depth of features. Both GitHub pages and Verscell can host websites. They're both web host platforms in that sense. But obviously you can do way more with Versell. You can go much deeper by having real compute that does real things. But you also don't have a database on Verscell. Once you need a database, you have to go horizontally to a different provider. The horizontal range is the range of things that you cover. The different feature sets that could exist in your app. It could be front end or back end. It could be design or hosting. It could be security, safety, firewalls, all those types of things in the web hosting world. But then the depth is how many features you have in a given one of those areas. The problem before was that the range was too hard to do. You couldn't compete with AWS because they already have a good solution in every single vertical you ever would possibly want to build in as a software developer. If you need a way to encode video, AWS has that. You need a place to store those videos, AWS has that. If you need a way to route traffic to different static sites, AWS has that. If you need a place to host your AI models when you're using them in your cloud, AWS has that. They have something that works in every single category you would ever want for your hosting, but they don't have every feature in every one of those categories. And that's how Versell was able to take a meaningful chunk of their business while still being built on top of AWS. They picked a vertical, which was full stack web hosting, and they built all of these crazy features in that vertical so that it felt bad to use anything else. By winning that vertical, they got their slice of this range, and now they have a real viable business in that section. You kind of had to do that though because building everything AWS supports is a suicide mission. You need expertise in every one of those areas to make a halfbaked version of the stuff they do or you can fixate on one vertical and build something so good that you feel bad using AWS. That is how startups have had to work for the last arguably 20 years because the amount of money it costs to do that wide range was just too expensive and too risky. If you had a team hired to build all of those things and it was wrong, it didn't make sense. Well, it didn't. But this is what's changed now. All of a sudden, it makes way more sense to try your best to cover that whole range of stuff. And the depth now is much less your problem. If you architect your solution in such a way that people can go deeper on the parts they need, if they can build their own solution to the problems you don't solve because you give them the right tools to do it in their space, they're good to go. There are some silly examples of this. I've even seen with my own services where I didn't add file storage to my recent cloud product that I've been building and others were able to hack it in by manipulating the database architecture which is insane that someone like built an image sharing service on my app that doesn't have file storage by breaking up the binary in the database but like you can do that now. Thanks Maria for scaring me about what my own services can do. On that note, I would like to show you what this type of thing looks like by talking a bit about the service that I'm building LakeBed. LakeBed is meant to be the shitty cloud for shitty apps. I don't know about you all, but I have a ton of random unfinished apps on my computer that kind of work that are useful for a few things that publishing is just more work than it should be to do. Of course, I can like deploy it on Versel pretty quick, but what happens when I need to go get a bunch of O tokens? What happens when I need to add inference with another provider? What happens when I need a database that I store things in? What happens when I need a preview environment that keeps these things linked together? All of that stuff was just annoying. And it was more annoying than building was. And that that annoyed me. To visualize this a bit, it kind of felt like building software took a lot of time before. Depending on what you were building, it could be a few days to a few weeks to a few years even. And when I was building before AI, just using cool things like the T3 stack to accelerate the speed at which I could throw together an app. something like for example marker thing, the service that I built for tracking all of the topics I talk about in a stream to streamline our chopping and getting the assets to my video editor. This took me 3 days to build the first time. I threw it away. I rebuilt it in a day and it was much better. And I've barely touched it since. This service in total probably took 30 to 40 hours to build. Deploying it probably took around 3 hours. getting all of the solutions for like the database architected and connected correctly, getting it deploying properly, getting the virtual environment set up, getting clerk and all the o layers in the Twitch tokens so that I could authenticate that properly all set up. All those things took a meaningful amount of time, but it was less than a tenth of my total time, so I didn't give a [ __ ] Now I do because I could build the same app in 30 minutes, but deploying still takes just as long. This pissed me off. O was annoying me enough that even with awesome solutions like work OS and clerk, I still had to spend too much time in dashboards, too much time attaching the pieces when all I wanted was a simple Google sign-in button. I built Shu to effectively be a Google O broker to abstract that layer so I don't have to build it into every single service or set up another app in another provider to do it. There is no dashboard and shoe for you as a developer. You just copy those two lines of code and now it works. This was going to be one of my next big projects. I was really excited about Shu. I'm still using it in a bunch of stuff and I think it's awesome. I have a lot of people who have been hitting me up to get this out there. I will still probably open source it eventually because I do think it's a cool project. Maybe I'll have a model that's allowed to do security stuff so I can actually make sure it's secure before I go public with it. But that all aside, I built this as a what I would call a glue solution. Not just cuz shoe glue rhymes, but because I was so fixated on the issues between the things I was caring about. When I was thinking here and I looked at the deploy time, I saw all the pieces and how they didn't quite come together, right? And historically, that's where I've spent my time. I spent my time finding the layer where things don't really go as smoothly as the rest does. That's why I love stuff like TRPC, making the relationship between a back end and front end much easier. It's a good glue solution between the back end and front end. That's why I built upload thing in 2023 because it was too hard to add file upload to your web apps and upload thing made it way easier to do a trivial file upload integration in your services. All of these things were built to make it easier to fix problems between stuff and that made sense in an era where we had these incredible verticals for every given category but the layers between them were where the problem started to occur. And that's why I made shoe as well because I noticed when I was building more and more of these apps that the need for a simple off layer was getting bigger and bigger for me. But then I kept thinking and I kept building and I kept doing other things to solve this. And I realized every time I fixed one of those thin layers that needed some glue, I just needed to fix the next one after and then the next one and then the next one. I was living in the margins in between these different verticals because none of them were built to integrate well with others and none of them were built for a world where agents can do all of the things they need as long as they can be resolved with code. These solutions were built in the era I'm from which was the gluing different services together era which is why I got really into building glue because I was used to building things that way. I don't think that makes sense anymore. So instead of building glue and instead of building shoe, I decided I had to go way further. And that's why Lake Bed exists. Instead of trying to plug the gaps between different pieces, I decided to take a sledgehammer to the whole thing. What if I reinvent the framework? What if I build my own runtime? What if I build my own cloud platform for hosting these things? What if I build my own bundler so you can bundle these apps in any environment without even needing a file system? What if I build my own database platform and primitive that integrates with all of this so that you can just go deploy things and not have to think about all of it? The code itself is the instructions for the deployment. Still very early in the development of Lakebed. I have some agents in the background making improvements as we speak. I am hoping to have this ship soon. I'm showing this because I want you guys to start thinking the way I am now. I want to encourage this boil the ocean mindset. this idea that we can finally go horizontal with the things we're building. That building a really good vertical isn't the only path to success anymore. And instead, building a shitty horizontal play, something that is bad but functional in every category someone might need. Building a shitty all-in-one solution suddenly makes way more sense because it can function and previously wouldn't have been able to function. Most demos for new dev tools tend to show them by building a new app using the new tool. I did things a little differently here. I built 10. I just spun up cursor agent with composer 2.5 so it' be a little faster. I am also running this with cloud code in the background. And as usual, cloud code's taking its goddamn time. When I did this here with a dumber, cheaper, faster model, it was able to deploy 10 apps that it built from scratch in maybe 8 minutes or so. Obviously, we got the standard to-do list app, but we also got a poll arena where we can create and manage polls. We got a recipe box where we can add and manage recipes. It needs a time. Cool. It's 54 minutes. Nice. And obviously this all syncs because why wouldn't it? It's a good product. Another one. And when the new recipe appears, it appears in both tabs and it will for all users as long as you've architected it as such. All these little things, including a one-click sign in with Google that behaves how it should behave, all just baked in to the platform itself. This is the type of thing that would have made no sense to build before because it's so many parts for a thing built for [ __ ] It was designed for shitty apps that probably shouldn't get thousands of users. The point here was to make it as easy as possible to put together these shitty apps so that I can use them for whatever I want to. And I can build quick one-off things for my team. I can host a page and send it to my mom to explain something to her. I can make a silly game where I have a pixel pet that needs to be fed and played with. All of these types of things could be done before, but the amount of work it took to get all the parts assembled was too much. And rather than build additional glue for each layer, I said, "Fuck it. I'm going to reinvent everything." And it went way better than I expected. The reason I built this wasn't so I could release it and be super successful or whatever because I wanted to hit the wall. I wanted to push and see where does this break down. When can I not keep going? At what point does building the whole thing, does boiling the whole ocean fail? and it somehow hasn't. That's the thing that's been crazy for me is the further I go with this, the more real it feels. And that it it [ __ ] with my brain and that's why I'm doing this now. And that's also why I'm making this video. I don't think we're building big enough right now as an industry. Developers are still trying to use these tools to automate the existing work they did before. They're not realizing that it enables different types of work. And that's where this stuff starts to get really, really fun. And that's why I'm even more excited for the follow-up video I'm going to do where I showcase some of the ideas that I wish someone else would build because I don't have the time to do it. Going big like this takes a lot of your energy and focus, and it's so fun, but I can only do it on one thing at a time. And right now, that thing for me is lake bed. I want to give you guys ideas for other ones. So, keep an eye out for that video. The point of all of this is to try to get you guys to think a little different, to try and push to things that wouldn't have made sense to build before because now it does. And those things are so fun to build. If you're not pushing yourself past what made sense before, you're not really using these tools for what they're capable of. And I highly recommend you find one of those ideas in the back of your mind, something that sounds like it shouldn't be possible, and push until you hit the wall. I think you'll be surprised just how far off that wall is. Let me know how that goes for you guys. And until next time, peace nuts.