Shipping Is a Skill

Most developers I know are good at writing code. Far fewer are good at shipping it.

This used to confuse me. The gap between "working on a project" and "people are using it" seems like it should be small. You write the code, you deploy it, you're done. But in practice, that last stretch — the part where you actually finish — is where most projects die. Not because of technical problems. Because of a different set of skills that don't get talked about much.

Shipping is a skill. It's learnable. And if you're consistently not finishing things, it's worth looking at it directly.

The perfection trap

The most common reason projects stall is that the person building them won't let them be imperfect.

There's always something that isn't quite right. The UI isn't polished enough. The error handling is incomplete. The architecture you chose six weeks ago looks worse now that you understand the domain better. The README is embarrassing. There's a refactor you've been meaning to do that would make everything cleaner before you show it to anyone.

None of that is the real problem. The real problem is that you're using quality concerns as a reason to avoid the exposure that comes with shipping. Putting something in front of real users is uncomfortable. It can fail. People can not use it, or use it and not care, or use it and find it worse than you hoped. Staying in the build phase indefinitely is a way to avoid finding out.

The antidote isn't lowering your standards. It's being honest about what your standards are actually for.

Scope is the variable

Every project I've shipped, I cut something. Usually several things. The features that seemed essential during planning turned out to be negotiable when I was staring at a deadline I'd set for myself.

This is intentional. I don't scope a project and then try to ship it. I scope a project knowing I'll cut things, and I try to identify in advance what can go. Not what I want to cut — what the project can survive without, while still being useful to the person using it.

There's a version of Barba Studio I planned that had analytics dashboards, multi-location support, a client-facing booking widget with custom branding, and an integrated loyalty system. None of that shipped in the first version. The first version had bookings, a calendar, and a way to send appointment reminders. That was the whole thing. People started using it the week it launched.

If I'd waited to ship the full vision, it wouldn't have launched at all.

The done definition

Before I start anything significant, I write down what done means. Not a full spec — a sentence or two. "This is done when a barber can create an account, add their services, and receive their first booking." That's it. Everything else is version two.

This sounds obvious. It almost never happens in practice.

Without a definition of done, a project has no natural stopping point. It just grows, indefinitely, as you learn more about the problem and accumulate ideas about what it could be. That's fine for a research project. It's fatal for something you want to ship.

The definition of done doesn't have to be minimal. It has to be specific. "Done when the core flow works end-to-end with no critical bugs" is a target you can actually hit. "Done when it's good" is not.

Momentum and re-entry cost

One thing I've learned building in the margins — in the hour before work, the Saturday morning, the gaps in a full schedule — is that momentum is more valuable than I used to think.

Shipping requires getting a project from wherever it is to done. The longer that takes, the more re-entry cost accumulates. Every time you pick the project back up, you spend time remembering where you were, what you decided, why. That's time not spent building.

The projects I've finished have almost all had a phase near the end where I pushed harder than usual — not because I was burning out, but because I could see the finish line and I knew the cost of dragging it out. Two focused weeks to close something out is usually better than six relaxed weeks that end in the same place.

That final push isn't a personality trait. It's a decision.

What you actually learn from shipping

There's a kind of knowledge you only get by putting something in front of real users. Not hypothetically — actually.

Which features they use and which they ignore. Where they get confused. What they complain about that you didn't expect. What they don't complain about that you agonized over.

All of that is information you cannot get any other way. And you only get it by shipping.

The feedback from a real user in the first week of a product is worth more than months of internal refinement. Not because your refinement is worthless — because the user tells you what to refine. Building in a vacuum, without that signal, is mostly just guessing.

The honest version

Some projects aren't meant to ship. Experiments, learning exercises, things you built to understand something — those have different success criteria, and that's fine.

But if you're treating something like a product — if you've told yourself it's going to be real, it's going to help someone, it's going to exist in the world — then not shipping it is a specific kind of failure. Not a moral failure. A skill failure. Which means it's fixable.

Write down what done means. Cut whatever doesn't fit in that definition. Make the last push. Ship the thing.

The second version will be better anyway.