Pick what you built. We'll walk you through what "shipped" means for that kind of project — the demo URL options, what your README needs, and what reviewers most often flag.
Shipping a web app or website
These are the easiest to ship well, and the easiest to ship badly. The bar is: someone clicks a link and uses your site without running any commands.
What "shipped" means here
Your site is deployed at a public URL. Anyone with the link can open it and see something working.
Where to host the demo
- Vercel, Netlify, or Cloudflare Pages for anything modern — Next.js, SvelteKit, Astro, plain static.
- GitHub Pages for static sites — fine for vanilla HTML/CSS/JS or built SPAs.
- Nest is recommended for projects with a backend or database. Paid tiers on Render or Railway are also good, but avoid their free tiers since they suffer from slow cold starts and aren't guaranteed to keep your app online indefinitely.
- A custom domain is a nice touch but not required.
What your README must include
- One-line description at the top.
- Live demo link (the one you put in the demo URL field, mirrored here).
- Screenshot or short GIF — voters skim these.
- How to run it locally if someone wants to.
Common reasons projects bounce
- Demo URL is the GitHub repo, not the deployed site — the most common reason web projects bounce.
- Site loads but the main feature is broken. Test the deployed build, not just localhost.
- Site requires a login but you didn't share credentials. Either provide a demo account or remove the gate for the demo.
Real examples
- saasheaven.space — TypeScript, deployed at a custom domain. Clear what it does within five seconds.
- TablissNG (browser new tab) — Pure GitHub Pages, no backend.