What It Means to Ship
Most builders spend their time building. Fewer spend serious time thinking about what happens the moment they stop building and start delivering. Shipping — releasing finished software to real users — is its own discipline, with its own craft, its own risks, and its own satisfaction. It is where code becomes consequence.
Shipping Is Not Finishing
There is a common mistake: treating 'done' and 'shipped' as synonyms. They are not. Finished means you are satisfied with the code. Shipped means other people are running it. That distinction matters enormously. When software is only on your machine, a bug is an inconvenience. When software is running for ten thousand users, a bug is a liability. The moment you ship, your choices have consequences that you cannot undo by pressing Ctrl+Z. Consider a real example: in 2012, Knight Capital Group deployed a trading algorithm. Within 45 minutes of going live, a shipping error — specifically a flag left in production code that was never meant to be there — caused the system to execute millions of unintended trades. The company lost $440 million. The software had been 'finished' for years. The problem was in the shipping.
Shipping is the act of releasing software to an audience beyond yourself — making it live, accessible, and operational for real users. It ends your exclusive control over the software's behavior and begins the software's public life.
Shipping involves several concrete acts: Deployment: moving code from your development environment to a server or platform that users can reach. Release: making the deployment accessible — flipping the switch so users actually see it. Announcement: telling people it exists (which is optional but nearly always necessary for anyone to use it). Handoff: some products have an explicit moment when ownership or support passes to another team or to the public. Each of these is a distinct step. Many products deploy successfully but never truly release — they sit on a server no one visits. Others release without announcing and wonder why adoption is slow.
The Minimum Bar for Shipping
What must be true before you ship? This is a judgment call, but professional builders have developed heuristics: Core function works reliably. The thing the product is supposed to do must work under realistic conditions — not just on your machine with your data. Failures are handled gracefully. When something goes wrong (network timeout, invalid input, server error), the product should give the user a useful message rather than crash silently or expose a raw error. You can fix problems quickly. You need some form of monitoring, logging, or user-feedback channel so you know when something breaks — and a path to push a fix. You understand what you are shipping. If you built something with AI assistance and you cannot explain what it does or how, you are not ready to ship it to others. This last point deserves emphasis in an era of vibe coding. AI can generate code fast. The speed of generation does not reduce your responsibility for understanding what you are releasing.
Flashcards — click each card to reveal the answer
AI can generate a working prototype in minutes, which creates pressure to ship immediately. Resist it. Fast generation is not the same as safe delivery. Run through your minimum bar checklist before you flip the switch.
Knight Capital lost $440 million in 45 minutes because of a shipping error. What does this example most directly illustrate?
A student builds an app that works perfectly on her laptop. She uploads it to a server but tells no one the URL exists. Which of the following is most accurate?
The Shipping Checklist Audit
- Step 1: Think of a small software project you have worked on — it can be a game, a website, a script, or even a homework submission system.
- Step 2: Apply the four minimum-bar criteria from this lesson: (a) core function works reliably, (b) failures are handled gracefully, (c) you can fix problems quickly, (d) you understand what you are shipping.
- Step 3: For each criterion, write one sentence assessing whether your project met it — and if not, what would have been required.
- Step 4: Write two to three sentences: based on this audit, was your project actually ready to ship? What would shipping it to 1,000 strangers have revealed?