Ship the Prototype

The belief

The prototype is the position. An idea stays hypothetical until it ships. Shipping converts a private build into a reusable artifact - something teachable, something iterable, something that compounds through feedback and public record.

The loop has a shape: build, post, learn, build again. Every step is load-bearing. Without the post, the build stays private and compounds nothing. With it, the artifact enters the world - citable, forkable, questionable. That is when it starts to compound.

How to apply

1. Default to shipping over pitching. Build a working version before pitching the concept. A prototype proves something a slide deck never can. Capability acquired before declaration is the model: build first, name what you can do second.

1. Treat the post as part of the build. The build is not done when the code runs locally. It is done when it is public. Posting is not distribution - it is the step that converts the artifact into something reusable by others and retrievable by your future self. The loop closes when it is posted.

1. Accept embarrassment as the admission price. A shipped prototype with rough edges beats an unshipped one with perfect architecture. Late arrival is still arrival. The market cannot give feedback on what it has never seen.

1. Use AI to lower the substrate cost, not to skip the ship. When tooling shrinks the effort from weeks to days, ship more things - not hold one thing longer for polish. The barrier dropped; the discipline does not drop with it.

1. Distinguish shipping from releasing into noise. "Ship the well-spec'd prototype" is the refined form of this belief. The verb stays constant. What tightens is the spec discipline upstream. Speed without a spec produces a plausible-but-wrong artifact. Speed inside a tight spec produces the real thing.

What this is not

• Not "ship anything and call it done." The belief is about lowering the barrier to public proof-of-concept, not about celebrating rough output for its own sake. The spec-over-sprint belief refines this upstream: when AI makes iteration cheap, the binding constraint is spec quality, not shipping speed. The two beliefs hold together.
• Not "public by default." Every shipped prototype in the corpus was posted publicly because those projects were designed to be public artifacts. Building substrate - internal tooling, private scripts, personal journals - does not require a LinkedIn post to count as shipped. The loop closes where the artifact is reusable.
• Not a solo-developer principle only. The claim applies anywhere a working version exists as an option and a pitch is chosen instead. The prototype is the position because it is verifiable. A pitch is not.

Argues against

• "The idea needs to be validated before we build anything."
• "We should wait until the prototype is polished enough to show externally."
• "Move fast on ideas in stealth - don't post until the product is ready to launch."

Where to go from here

If you want the parent theme that holds this belief alongside related projects and tinkering patterns, go to personal-projects-tinkering. It frames how side projects function as a positioning and learning system.

If you want the belief that refines shipping discipline upstream, go to spec over sprint. It tightens the work that happens before the build starts - the two beliefs hold together.

If you want the surface where shipped prototypes close their feedback loop, go to linkedin-as-instrumental-platform. Shipping creates the artifact; that belief handles the posting layer.