Ship Software That Does Nothing

You should ship software that does nothing. Absolutely nothing. I’m not being cheeky about this. I have no hidden meaning. The very first thing you should deliver when you start a new web application is absolutely nothing.

Many people will tell you to ship a minimum viable product. Others say to ship a prototype to get feedback. Not me. I think you should ship a blank page to your production servers on day one.

Consider the alternative. You could spend a day debating your architecture: slices, layers, shapes, vegetables, or smalltalk. You could spend several days eliminating the biggest risks by building proofs-of-concept to eliminate unknowns. You could spend a week figuring out how you’ll store, search, and cache data and which third–party integrations you’ll need. You could spend a couple weeks creating mockups and getting feedback from potential users. You could spend a month building an end-to-end product that focuses on the highest-ROI feature for a niche target market. No matter what, you still have to ship. And no matter what, you could’ve shipped nothing first.

You can evolve your nothingness, feature by feature, into your preferred architecture. You can build your riskiest features in the blank space you created by shipping nothing. You can add tools and providers one by one as your features demand. You can ship your mockups to production to drive your user interviews. All of this is made easier and lower risk by shipping nothing first.

Shipping nothing is nothing to sneeze at. Delivering a blank page to production means you’ve made a lot of important decisions. You must take risky actions early, which is the best time to take risks. And once you’ve shipped software that does nothing, making it do something is easy.

You can’t ship a webpage that does nothing until you have a place to ship to. You’ll have to decide whether you’re deploying to cloud VMs, rented bare metal, a rack in the datacenter down the street, or a serverless function. You’ll pick your programming language. You might pick a framework, a web server, and a containerization strategy. Shipping nothing pushes you to set up deployment automation immediately. You solve your administrative burdens—domain name, certificates, billing—when it’s easy. When there’s no pressure. Your stakeholders aren’t pressuring you to ship because it’s been no time at all. Your users aren’t clamoring for access because they haven’t seen anything yet. Ship software that does nothing, and ship it to nobody.

If you ship nothing to nobody, it’s guaranteed to work. You won’t hear the phrase “but it worked on my machine.” Once you’ve delivered nothing, every bit of something goes right to production. You’ll notice anything that doesn’t work before it becomes expensive to fix. You’ll notice because you’ll automate the shipping.

Creating a repeatable build process for nothing is easy. It has no dependencies. Nobody has ever configured a production server by hand. There’s nothing to audit, and nothing has been done that makes automation tricky. Automate your deployment to production before you can produce anything more than a blank page.

A blank page is also easy to test. 200? OK. For the same reason automating delivery was easy, automate integration as well. Creating your health check infrastructure is much easier when you only have to check one thing. The same goes for setting up continuous integration. And since you’ve set up continuous integration, that means you’ve set up version control. There’s no need to decide between trunk-based development, git flow, or feature branches yet. Nothing is in progress. There is only main. So, set up a continuous integration pipeline to test main on every commit. Set up a continuous deployment pipeline to deliver main to production every time the tests pass. Configure alerts so that everybody knows when something fails.

Notice how much is involved in shipping software that does nothing. This work will come around eventually. The later you do it, the riskier it is. When your system has few dependencies, there is little chance you forgot one. When your application has no functionality, you can’t have features that aren’t covered by tests. When you establish an automatic delivery pipeline before you have users, everybody is accustomed to frequent, tiny changes. But if you wait, these all get harder. Building software that does something and then figuring out how to ship is risky. Shipping software that does nothing slices that risk into tiny pieces.

You address one piece of risk—possibly the largest—when you ship software that does nothing to production. After that, each feature you add addresses a bit more of the risk. When you ship a feature that requires persistence, you’ll add a persistence mechanism. You’ll cover each feature with automated tests. “It’s just one small feature, I might as well.” You’ll build toward your desired architecture bit-by-bit. No single task ever becomes a burden. Every commit makes it to production. Soon you’ll have your MVP. There will be no moment of panic, no mad dash to the finish line.

In fact, there never has to be a finish line. You can invite your first users to try features immediately. You get valuable feedback that can shape your roadmap. Users get some of the value sooner than they would’ve otherwise. By shipping software that does nothing, you’ve figured out how to ship the right something, sooner.