"Shipping"
On this page

What is "Shipping"?

Most people don't know how to ship a project. People can build incredible things without shipping them. But if it only lives on your computer, does it actually exist?

Shipping is the process of making your project sharable. It's almost as important as the project itself.

When you first make something, it lives as files on your computer. Only you can access it. Nobody else can see it. When you look back in a few years, it'll be very difficult to remember anything about it.

The Three Minimums

1. Document what your project is

  • Why did you build it? Your motivation and story.
  • A short description of what it does.
  • How it all fits together, with photos of your design.

2. Make it understandable and organized

All files and resources should be easily accessible and well-organized. Include source files so someone else could replicate or build on your work.

When your project is nothing but a dump of files and two sentences for a README, it's hard for anyone to recognize your work or learn from it.

3. Make it public and online

Your project has to live on GitHub where other people can actually read and clone it. Private repos and "download this zip from Google Drive" do not count.

Heavy unpolished AI usage will be rejected

AI assistance is allowed when the result is work you actually understand and have polished. A project that's mostly raw AI output, with no human review, refinement, or iteration on top, will be rejected at review. Reviewers will ask you to explain how your code works, and "the AI wrote it" is not an answer. See Fix My Project for how to recover if your project gets flagged for this.

  • If you are brand new to GitHub, follow the Software Setup page first. It walks you through installing GitHub Desktop and making your first commit.
  • Create a public repository. In GitHub Desktop, go to File → New repository, name it after your project, do NOT tick "Keep this code private", and push it.
  • Write a real README: one line that says what it is, a short paragraph about why you built it, setup instructions for anyone who wants to try it, and photos for hardware projects. The What Makes a Good Project? page has examples.
  • Add a LICENSE file. MIT is a safe default for most teen projects. GitHub's "Add file" button has a LICENSE template that fills it in for you.
  • Add topics on the repo page (e.g. hardware, pcb, keyboard) so the project is findable. Pin it to your GitHub profile once you are proud of it.

Examples of Well-Shipped Projects

By Hack Clubbers

These were all built by teenagers. Notice how each one has a clear README, source code, and you can immediately understand what it does:

Software:

  • DoomPDF. Doom (1993) running inside a PDF document. By Allen, 18.
  • Vert. A file converter that uses WebAssembly to convert files on your device. By Maya, 17.
  • Specter. A game about a knight escaping a cave, haunted by his own ghost. By Ayessa, 18.
  • Blind Defusal. A two-player cooperative bomb defusal game. By Joshua, 17.

Hardware:

Also worth a look: LibrePods, AirPods liberated from Apple's ecosystem. By Kavish, 17.

Outside of Hack Club

These are real open-source projects with great documentation. Notice how they all have instructions and are public for anyone to learn from: