In Stardance, "shipping" is the moment your project becomes real to other people — not just to you. It's when you stop building in private and put something out where strangers can poke at it, vote on it, and decide it's worth Stardust.
This guide walks through what actually happens when you click that big Ship It! button — and what you should have ready before you do.
The 60-second version
- You click Ship on your project.
- A reviewer (we call them Shipwrights) checks that your project is real, runnable, and demoable.
- If approved, your project enters the voting pool. Other people are randomly shown your project and rate it across four categories.
- After enough votes come in, your scores determine your payout in Stardust — anywhere from 1 to 30+ per hour you logged.
- Stardust converts to prizes in the shop.
That's the whole loop. Build → ship → review → vote → payout → prize. Everything else in this guide is detail on doing each step well.
What reviewers actually check
Shipwrights aren't grading you on cleverness or polish. They're checking a small set of practical things:
- Can someone actually try it? A demo URL has to lead to a live, playable, runnable thing — not your GitHub repo, not a "coming soon" page.
- Is the source public? Your code URL has to point to a public, cloneable GitHub repo (or equivalent). No private repos, no zip files dumped in Drive.
- Is there a README? Linked from your project. We'll get to what makes a good one.
- Does the project look like a project? Description, screenshot, at least one devlog showing real progress.
- Is the time real? Hackatime tracked actual coding time — not 8 hours of staring at a config file.
None of those are arbitrary. Every one of them is something a future voter will need to look at when they decide whether your project deserves their vote.
The single most common reason projects bounce back: the demo URL points to the GitHub repo instead of an actual deployed/playable thing. If a reviewer can't try your project in under a minute, it's not shipped.
What "demo URL" means for your project
This is the part that trips people up most, because it depends entirely on what you built. Some examples:
copy.sh/v86).If your project genuinely can't be deployed (custom hardware, a kernel patch, etc.), a high-quality video demo is the right answer — and we'll cover that case in the project-type guide.
Open the project-type guide →What happens after you ship
Approval doesn't immediately mean "you got Stardust." It means your project is now in the voting pool. Voters are randomly assigned your project and asked to score it from 1–9 on four categories:
- Originality — how distinct is the project from common projects?
- Technicality — how much effort did you put into the implementation?
- Usability — could someone actually use it? Did they enjoy using it?
- Storytelling — how well did you document the development journey through devlogs, documentation, commit messages, and your README?
Once enough votes come in, these scores combine into a quality multiplier. A well-rated project earns ~30+ Stardust per hour you spent. A barely-passing project earns closer to 1. The difference is enormous, and it's almost entirely determined by whether you took shipping seriously.
What ship-readiness looks like, in one sentence
A complete stranger could open your demo URL, your README, and your project page, and within five minutes know what your project is, why it's interesting, and how to try it themselves.
If that's true, you're ready. If it's not, the next two guides will help you get there.