If you know Adam Savage, you’ll be familiar with his work as a professional model maker who built props and miniatures for major films, including multiple Star Wars movies before becoming co-host of MythBusters.

In recent years, he has become just as well known for his One Day Builds: time-boxed projects where he commits to building something start to finish in a single day. The constraint is the point. By limiting time and scope, One Day Builds short-circuit perfectionism, reduce paralysis by choice, and replace overthinking with forward motion. The result isn’t always flawless, but it’s finished, functional, and energizing.

That combination of momentum, learning, and visible progress is exactly why the One Day Build mindset translates so well beyond the workshop and into how we think about building tools and infrastructure in software engineering.

The Principles of a One Day Build

Define "done" before you start.

We'll talk about what makes a good candidate project later, but what's key is that you know what you want the outcome to be. Most important is that you frame your goal in terms of usability. "What can I build that will work tomorrow?"

Establish ruthless time boxing.

If you have watched enough one day builds, you will realize that they are not all really one day. That's fine. The goal should always be one day. Sometimes things get a little more complicated than you realize, and that's fine too. Ultimately, doing is learning. But learn how to cut things off. Learn how to say "This is where I stop."

Value momentum over perfection.

Building software is a series of decisions, each one informing the next. You will quickly learn that a surprising amount of the time you spend building is considering these choices. In order to maintain momentum, you will need to make these decisions faster than you are comfortable with. You will likely not be very happy with your first few one day builds. Decisions you made in the heat of the moment you may regret. That is learning. Repeated builds change your mindset. You will get better and better at making rapid decisions that you will be happy with in the long run.

Picking a Candidate Project

To me, there are two especially strong candidates for a One Day Build. The first is learning something new. Picking up a new programming language, experimenting with RAG, or building a proof of concept for a headless CMS are all great examples. These efforts benefit enormously from a hard time-box, because the goal isn’t mastery, it’s orientation.

When you’re learning a new technology, the real objective is to understand what you like and don’t like about it, where it shines, and where it fights you. In addition to choosing the target technology, it helps to define a “Hello World" scale problem that’s just big enough to be meaningful. Curious about Java threading? A One Day Build might explore which workloads benefit from virtual threads versus classic thread pools, and where each approach breaks down.

The second category is automation, frameworks, and internal tools, especially in environments carrying significant technical debt. These problems often linger not because they’re unsolvable, but because teams are waiting for the perfect solution or the right time. Better logging, improved monitoring, richer build metadata, or using AI to analyze historical data for reporting; many of these can be meaningfully improved with a small, focused effort. Even if the result isn’t perfect, you reduce friction immediately, and almost always learn something valuable in the process.

Telling the Story

When I interview candidates, one of the key things I evaluate is their ability to tell a clear, coherent story. I’m not interested in a laundry list of frameworks and technologies, they’re easy to memorize. What I want to hear is a battle story: a real problem, real constraints, and real trade-offs.

One Day Builds are excellent raw material for these conversations, especially when framed in the STAR format. What was the challenge? How did you approach solving it? What went wrong along the way? How did those mistakes change how you think as an engineer? What opinions did you form about the tools you used? Answers to these questions demonstrate genuine, hands-on experience far more effectively than any programming test or quiz-style interview ever could.

What's Next?

Do it! Set aside a day and start now!

Remember: Doing is learning. The mindset shift you gain is worth at least as much as the tools you end up with at the end of the day.