Most engineers think building is the hard part. It isn’t.

Building has well-defined problems. You understand what you’re trying to make. You can measure progress. You can debug failures and trace them to their causes. There’s satisfaction in each commit, each passing test, each feature that works as designed. The feedback loop is tight. The domain is yours.

Distribution is different. The problems aren’t well-defined. You don’t know which channels will work or why. You can do everything right and get nothing back. You can do something completely wrong and get lucky. The feedback loop is slow and noisy and often misleading.

And yet distribution — getting the thing to people who will actually use it — is roughly 70% of the work.

Why Engineers Get This Wrong

The mismatch comes from training. Software education, open source culture, the entire mythology around technical craft — all of it rewards building. The hero of every story is the person who wrote the clever thing, not the person who figured out how to reach the customer who needed it.

So engineers build for a long time. They add features before shipping. They refine before showing. They perfect the architecture before putting it in front of anyone. This feels like progress. It produces something real and measurable. And it is progress, up to a point.

That point arrives much earlier than most people think.

The Compression

The practical implication is uncomfortable: every week you spend polishing before shipping is a week you delayed learning whether the thing is worth polishing.

The market doesn’t reward clean code. It doesn’t notice elegant architecture. It responds to one thing: does this solve a problem I have, right now, better than the alternatives? You cannot answer that question from the inside. Only someone outside, with real stakes, can tell you.

The habit to build is to compress the building phase — get to something demonstrably useful as quickly as possible, then use real feedback to determine what actually needs to be built. Most of what you thought needed to be built before shipping didn’t. And some of what you’d never have guessed needed building becomes obvious the moment someone real uses it.

The Other Work

Distribution isn’t mysterious, but it is unfamiliar to most engineers. It includes finding the people who have the problem you solve, reaching them in a way that doesn’t feel like an intrusion, helping them understand quickly that you’ve solved their problem, and then iterating on all of that based on what actually works.

This is a different skillset. It rewards different things — patience, consistency, the tolerance for rejection, the ability to learn from ambiguous data. It doesn’t look like progress the same way code does.

But it is progress. The user you talk to who tells you your onboarding is confusing — that’s progress. The search result that brings someone to your landing page two months after you wrote the post — that’s progress. The referral from a customer you treated unusually well — that’s progress.

The 70% is slower. It’s less satisfying on a per-day basis. But it’s the part that determines whether any of the building mattered.

Build fast enough to learn. Then learn.