The Difference Between Being Busy And Actually Building

When I was building my second video editor, I was writing code every day. Long sessions, late nights, the kind of focused work that feels productive while you’re in it. The project was a non-linear editor written in C++, and I had convinced myself that the language was the right choice because video editing demands performance. Performance requires C++. That was the logic.

What I didn’t account for was how much of my time would go into work that didn’t move the product forward. I’d spend a week implementing a single UI panel. Not because the panel was complicated, but because everything around it was—the event system, the memory management, the platform-specific code, the rendering pipeline. Each piece of low-level infrastructure had to be built before I could even see the panel on screen. I was busy. Constantly busy. But the product wasn’t getting closer to being usable.

The realization came slowly. I’d look back at a month of work and struggle to point to anything a user would notice. The codebase had grown. The architecture was cleaner. The infrastructure was more robust. But the product itself—the thing someone would actually use to edit a video—was still barely functional. I had been busy, but I hadn’t been building. I’d been preparing to build, which is a different thing entirely.

The Illusion of Progress

Busyness feels like progress because it has all the external markers. You’re writing code. Commits are going in. The line count is climbing. There’s a sense of momentum, of forward motion. But momentum in the wrong direction is not progress. It’s just motion.

The hardest part is that the busy work often feels important. Building infrastructure, refactoring code, optimizing performance, setting up tooling—these are all legitimate activities. They’re the kind of work that responsible developers do. But they can also be a form of procrastination, a way of avoiding the harder work of actually shipping something and discovering whether anyone wants it.

The C++ editor was a masterclass in this illusion. Every day I was solving real technical problems. The problems were hard, and solving them felt like an accomplishment. But the problems were all in the service of an architecture that was too heavy for the product I was trying to build. I was optimizing the foundation of a house that nobody had asked for.

What “Actually Building” Looks Like

Actual building is different from busy work in one crucial way: it moves the product closer to being used by real people. Not closer to being architecturally pure. Not closer to being well-engineered. Closer to being used.

That’s a specific and uncomfortable standard. It means that a feature that lets someone import a video and cut it is more valuable than a beautifully designed memory management system. It means that a rough UI that works is better than a polished UI that doesn’t. It means that shipping something imperfect is often more important than refining something that isn’t shipped at all.

The switch to Electron for TrailStudio was driven by this realization. Electron wasn’t the “right” choice from a performance perspective. It wasn’t the choice that a systems programmer would make. But it was the choice that let me build the actual product—the timeline, the editing workflow, the features that users would touch—instead of spending months on infrastructure that users would never see. The trade-off was real, but it was worth it. Electron let me be a builder instead of being busy.

The Metrics That Matter

If you want to know whether you’re busy or building, look at what you’ve shipped. Not what you’ve written. Not what you’ve refactored. Not what you’ve optimized. What have you actually put in front of users, and what have they done with it?

For a solo developer, this metric is brutal because it exposes how much of the work was preparation rather than production. The C++ editor had months of preparation and almost nothing to show for it. TrailStudio, once I switched to Electron, had something usable within weeks. The difference wasn’t effort. It was the choice of what to spend effort on.

The teams that fall into the busy trap are often the ones that measure the wrong things. They measure commits, or lines of code, or hours worked. Those metrics all go up when you’re busy. They don’t go up when you’re building. The metric that matters is shipped value—features that users can actually use, improvements that users can actually feel. Everything else is noise.

The Fear That Drives Busyness

Why do we choose busy work over building? Often, it’s fear. Building means shipping something that might fail. It means putting work in front of users and discovering that they don’t want it. Busy work is safe. Refactoring code, improving infrastructure, optimizing performance—these activities can’t fail in the same way. They’re always “progress” in some abstract sense. They protect us from the vulnerability of actually shipping.

But that protection is an illusion. A product that never ships is a product that has failed, just more slowly. The months I spent on the C++ editor were safe in the moment—I was always making progress on something—but they added up to a product that never reached a user. That’s not safety. That’s a slower form of failure.

The teams that build things are the ones that can tolerate the fear. They ship imperfect work. They put things in front of users before they’re ready. They accept that some of what they build will be wrong, and they treat that not as a failure but as information. The fear doesn’t go away. It just stops being the thing that drives the decisions.

The Discipline of Shipping

There’s a discipline to actually building that has nothing to do with technical skill. It’s the discipline of asking, at every moment, whether the work you’re doing is moving the product toward use. Not toward elegance. Not toward efficiency. Toward use.

This discipline is hard because it requires saying no to work that feels valuable. The refactor that would make the code cleaner but doesn’t change what users can do. The optimization that would make things faster but isn’t necessary yet. The infrastructure that would be nice to have but isn’t blocking anything. These are all things that feel like building. They’re all things that are actually busyness in disguise.

The discipline is also hard because it requires finishing things. Starting a feature is easy. Finishing it—making it work, testing it, shipping it, seeing how users react—is hard. The last 20% of a feature is where most of the real work happens, and it’s where most projects stall. The team that starts ten features and finishes none is busy. The team that finishes one feature and ships it is building.

The Shift

The shift from busy to building is not a single decision. It’s a reorientation of attention. It’s learning to notice when you’re doing work that feels productive but isn’t moving the product forward, and choosing to do something else instead.

For me, the shift happened when I looked at the C++ editor and realized that months of work had produced almost nothing a user could touch. The realization was uncomfortable. It meant admitting that a lot of that work was wasted—not because it was bad work, but because it was the wrong work. It was work that served the architecture, not the product.

The shift to Electron was a direct response. It was a choice to prioritize building over busyness, even if it meant accepting trade-offs that a purist would reject. And it worked. TrailStudio went from an idea to a usable product in a fraction of the time the C++ editor had taken. Not because I was working harder, but because I was finally working on the right things.

The Question to Ask

The question that separates busyness from building is simple: what did I ship that a user can see? Not what did I write. Not what did I improve. Not what did I prepare. What did I put in front of someone, and what happened when they used it?

If you can’t answer that question, you’re probably busy, not building. And the fix isn’t to work harder. It’s to work on different things. It’s to choose the work that moves the product toward use, even when that work is less interesting, less elegant, less impressive. The product doesn’t care how busy you were. It only cares whether it works. And the only way to find out is to ship something and see.