Theo: Think Bigger When AI Makes Building Cheaper

Software development has changed fundamentally. It is understandable to see faster AI-assisted work as a threat to engineering jobs, but I am excited about the other side: things we can now build that did not previously make economic sense. This is a way of thinking about what to build, rather than a guide to a particular tool.

Think about the cloud. Before it, trying a new service often meant buying and provisioning physical machines and predicting demand. Too few servers could fail under load; too many wasted money. The cost and uncertainty made experiments expensive.

Cloud infrastructure changed that calculation: start smaller, add capacity as demand grows, and experiment without first assembling a huge infrastructure team. I see AI as another change in the economics of building, not proof that software work will disappear. That is an analogy and a prediction, not a guarantee about jobs.

Building has also required predicting how many engineers to hire for each product. If customers prefer the web app to the mobile app, for example, staffing decisions can suddenly look wrong. I have laid off a team before, and the effect on people makes experimentation emotionally costly as well as financially risky.

I think the new tools can make it possible to attempt some larger projects without hiring at the same scale. If writing code becomes cheaper, we should revisit assumptions about project specifications, team structure, releases and what is worth replacing. That does not mean the other costs of building and operating software vanish.

Consider Salesforce. Some of its features are needed by almost every customer; others matter mainly to larger companies; many more serve unusual needs. A challenger might build the common features and still find that a customer cannot switch because it relies on one or two less common ones.

Suppose a customer needs twelve features and your alternative has ten. Making those ten better does not necessarily overcome the missing two. My rough percentages about how little of Salesforce any one company uses are illustrations, not measured statistics; the point is that each company may need a different small slice.

Historically, a competitor either had to build a vast feature set, or create extension mechanisms and ask customers to do the work before they knew whether switching was worthwhile. Both are difficult. That is why I think a change in the cost of making and adapting software opens up a different approach.

Imagine a product across two dimensions: breadth is the range of categories it covers, while depth is the richness within a category. In hosting, static sites, compute, databases and video are different areas; each can have its own depth of features.

AWS offers a wide range of services. Vercel found an opportunity by going deep on full-stack web hosting, even while using AWS infrastructure. Historically, a startup often had to choose one such vertical because covering the whole range demanded too much money, expertise and risk.

I think it is now more plausible to cover a broad range at a basic level and let users go deeper where they need to. The architecture has to give them useful ways to extend it. Someone even built image sharing on my cloud project by storing binary data in its database despite the absence of a file-storage feature.

That project is Lakebed, which I describe as a simple cloud for rough little apps. I have many unfinished but useful apps where deployment requires more coordination than it should: authentication, provider tokens, inference, a database and preview environments all need to fit together.

For example, my Marker Thing app helps track stream topics for my editor. I estimate the original development and rebuild took 30 to 40 hours in total and deployment around three hours. With current tools, I think I could build the app in half an hour, but connecting and deploying the pieces can still take hours. These are my experience and estimates, not a controlled benchmark.

I built Shoe as a Google authentication broker to make sign-in easier without repeating setup for every service. It is what I call a glue solution: it smooths an awkward connection between existing products. I have long liked this kind of work, as with tRPC between frontend and backend and UploadThing for file uploads.

But each time I fixed one integration, another awkward layer appeared. These products came from an era of assembling specialized services, and I began questioning whether more glue was the right answer for a world where agents can work through problems expressed in code.

So I pushed further with Lakebed: a framework, runtime, cloud hosting, bundler and database primitive designed to fit together, with code describing deployment. It was still early when I recorded this video. The goal is a broad, functional system for modest apps, not a claim that it already replaces every mature cloud service.

For a demonstration, I asked an agent using a faster model to build and deploy ten apps; I estimate it took around eight minutes. They included a to-do list, polls and a recipe box. In the recipe example, updates appeared across tabs, and Google sign-in was built into the platform.

These are small, one-off projects: a tool for my team, a page to explain something to my mother, or a simple virtual pet. Such apps were possible before, but assembling all the required pieces took too much effort for their value. Lakebed is my attempt to reduce that friction across the whole stack.

I also built it to find the limit: when does attempting the whole thing break down? So far, it has felt more real the further I have pushed. That is my experience with an early project, not evidence that every ambitious rebuild will work or that the operational challenges are solved.

I worry that developers are using these tools only to automate the work they already did, without considering different kinds of work. Big projects still demand energy and focus, and I can only pursue one at a time. In a follow-up, I plan to share ideas I do not have time to build.

Find an idea that once seemed impractical and push until you reach its limits. You may discover that the wall is farther away than you thought. Experimenting with a bigger scope is how I want us to learn what these tools make possible.