Guides / Public page
How to make a free public page for your side project
You built something. Right now the only proof it exists is a GitHub repo and a localhost tab. A public page is the difference between "a folder on my machine" and "a thing I can send to someone." Here's what to put on it, what your free options actually are, and how to get one live today.
Why a repo isn't enough
A GitHub repo is for people who want to read your code. That's a tiny fraction of the people you want to reach. A potential user, a future employer, someone scrolling a launch post — none of them want a README full of install instructions. They want a single link that answers, in ten seconds: what is this, who is it for, and is it real?
A public page is also where the compounding stuff lives. It's the URL you put in your X bio, the destination for a Show HN post, the place people land from search. Without it, every bit of attention you earn leaks away because there's nowhere to send it.
What actually belongs on a project page
You don't need much, but you do need the right things in the right order. A project page that converts a visitor into a user usually has:
- A name and a one-line tagline. Not clever — clear. The visitor should know what it is before they scroll.
- A short "what it does" and "who it's for." Two or three sentences. Specific beats impressive.
- 3–5 key features. Concrete capabilities, not adjectives. "Reads your GitHub commits" not "powerful integrations".
- A way to follow or subscribe. Most visitors aren't ready to sign up — but they'll leave an email to hear when you ship. Capturing that is the single highest-leverage thing on the page.
- Links out — to the app, your X, the repo if it's open source.
- Signs of life — a recent update or changelog entry so the page doesn't look frozen in time.
Notice what's not on the list: long feature essays, a pricing table for a product with zero users, a blog with one post. Add those when you need them, not before.
The free options, honestly compared
A GitHub README or GitHub Pages
Free and zero new accounts. But it reads like documentation, has no email capture, and "github.com/you/repo" doesn't feel like a product. Fine as a stopgap, weak as a front door.
Notion / a shared doc
Fast to write, but it looks like a doc, not a product, and you can't capture followers or point a real domain at it cleanly. Good for an internal spec, not a public launch.
A site builder (Carrd, Framer, a static site)
You get a real-looking page and full control. The cost is time: you're now writing copy, choosing fonts, and fighting layout instead of building your project. For a one-pager this can be an afternoon you didn't plan to spend.
Hand-coded landing page
Maximum control, maximum yak-shaving. Worth it once the project is your main thing; overkill for a weekend build you just want to share Monday.
What "good" looks like
The bar isn't a design award. The bar is: a stranger lands on it, understands the project, and either signs up or leaves their email — all without scrolling past three screens of fluff. Speed matters too. A page that takes four seconds to load on mobile loses people before the headline renders, so keep images light and avoid heavy frameworks for what is, fundamentally, a page of text and a button.
The fastest version of all of this
Viestro builds the whole page from your existing project URL: it reads your site, drafts the name, tagline, description and features, and gives you a hosted page at viestro.dev/you with a follow button and a changelog built in. Everything is editable, and it's free for your first project.
You don't need the perfect page. You need a real one — a single link that makes your project feel like it exists to someone who isn't you. Get that live, then point everything at it.