Straight into GitHub Issues
Every note opens as a labeled issue in your repo, ready to triage and work. Nothing to copy out of a doc, no DMs to chase down.
Preview before production
Preview Dog is a private, production-like copy of your site you can open, share, and check before it goes live. Catch the rough edges, get a second pair of eyes, and ship with a little more confidence.
Make the headline bigger — it’s the first thing people read.
Jordan · just now
Issue #128 opened
from that sticky note
The idea
A preview is a working copy of your site, built from a branch or a pending change, that looks and behaves like the real thing — but isn't public yet. It lives at its own private link. You can click around it like a visitor would, except mistakes here cost nothing.
Think of it as a dress rehearsal: the same stage, the same lights, no audience.
Why preview
Most launch problems are obvious in hindsight and invisible in a code diff. A preview is where they show up while they're still cheap to fix.
Real layout, real content, real data shapes. Plenty of things look fine in a component and wrong on the actual page.
Share one link with a teammate or client and let them look before it's public. Approval beats apology.
Try the risky change somewhere it can't hurt anyone. The live site stays boring, which is exactly what you want from it.
A wrapped button, a typo, a broken link on mobile. Easy to miss in review, easy to catch on the real page.
Terminology
Most teams run the same site in a few places, each with a different job. The names vary, but the shape is usually this:
The version running on your own computer while you work. Fast, messy, and seen by no one but you.
A built copy at a private link, made to mirror production. Where review, feedback, and sign-off happen. This is Preview Dog's home.
The real site your visitors use. The goal is that nothing surprising ever lands here — because it was already seen in preview.
Best practices
None of this is exotic. It's the short list most teams arrive at eventually.
A preview is for the people reviewing it, not for search engines or the public. Gate it, and never let it get indexed.
Same build, similar data, same behavior. The closer the preview is to production, the more its approval actually means.
Reviewers shouldn't need to install anything. A link they can open on their phone is the whole point.
Scattered screenshots and DMs get lost. Notes that land next to the work — in your tracker — get fixed.
Previews are disposable by design. Spin one up per change, throw it away when it merges.
Whatever helps you review should disappear the moment a build is production. Visitors should never see it.
Why Preview Dog
A thin banner rides on your preview builds. A reviewer points and writes a note — and Preview Dog turns it into something your team can act on, in the place they already work.
Every note opens as a labeled issue in your repo, ready to triage and work. Nothing to copy out of a doc, no DMs to chase down.
Bugs arrive reproducible — steps, expected vs actual, environment. Feature requests arrive as user stories with the value spelled out.
A built-in assistant reads the issue stream, so anyone can ask “what’s most critical?” and get a straight answer.
Attached to every note
Early and open — it's on GitHub. No signup, and nothing here is for sale yet.
The name
Dogs notice what you don't.
A sound from two rooms away. A scent that doesn't belong. Someone at the door before the doorbell even rings.
They're always watching, always checking, always a step ahead.
Preview Dog does the same for your website. It rides along on every preview, helps your team flag what looks off, and turns a stray observation into a tracked issue before any of it ever reaches production.
Every change gets another set of eyes before it goes live.
Fast. Loyal. Always on watch. Because the internet shouldn't be the first place you discover a mistake.