Why Real Code Progress Beats Sandbox Screenshots in Build-in-Public

Sandbox screenshots are theater. Commit graphs are receipts.

Every "build in public" thread I have ever seen leans on screenshots. Founder posts a frame from a Lovable preview, three hearts float in, somebody asks "what stack is that" and the thread ends. Two weeks later the project is dead and the screenshots age into nothing.

Compare that to a thread anchored by a GitHub repo with a live commit graph. Same product, same marketing, but the receipts are different. The repo does the talking.

That's the gap. Build-in-public works when the thing you're building is owned, versioned, and walkable. Anything less, and you're selling vibes.

What screenshots actually prove

A screenshot of a sandbox session is a still image. It proves one thing: a UI rendered once, in that tool, in that moment. It says nothing about the codebase behind it, whether the commit history is real, whether the build is reproducible, or whether anyone but the author can run it.

You can fake a screenshot in five minutes. You cannot fake a public repo with a year of commits, real CI runs, and an issue tracker full of work that actually got shipped. The first is content; the second is evidence.

That difference compounds. A reader who clicks through a GitHub repo and sees a steady stream of real PRs — labeled, reviewed, merged — leaves with a different impression than a reader who sees a polished hero card on a landing page. The repo is a walkable artifact. The landing page is a poster.

Why commit history beats commit count

New founders love the green-squares aesthetic. A full contribution graph is satisfying but it is not the thing that makes a build-in-public thread credible. Three signals matter more than density:

1. Commit messages that read like engineering notes, not "fix stuff". A reader skimming git log --oneline should be able to tell what shipped, in plain language, in chronological order.
2. Branches and PRs that map to features, not one eternal main with everything force-pushed. The shape of the repo is the proof that someone thought about decomposition.
3. Tests, migrations, and config as first-class commits, not squashed into a single "launch" commit. The boring stuff is what makes the codebase believable.

A repo with 200 commits all on main and no tests is barely better than the sandbox. A repo with 80 commits, real branches, real CI, and a README that explains how to run it is a different product.

# Good — engineering notes, real work
$ git log --oneline --graph --all
* a3f9c2d  Add token refresh before Stripe webhook
* 7e1b4a0  Migrate auth to session cookies, drop localStorage
* d82c105  Fix off-by-one in streak counter
* 91ab330  WIP: refactor plan picker, do not merge

# Bad — polished PR theater
$ git log --oneline
* 4f2a9c8 Launch
* 8c1d3e2 First commit

The compounding loop

Once the repo is real, the build-in-public thread starts generating its own gravity. A reader opens an issue, you close it — that's a public transaction. A reader opens a PR, you review it — that's a public conversation. A reader clones the repo, runs the dev server, files a bug — that's a public user.

None of this happens against a sandbox. The sandbox is owned by the platform. The repo is owned by you. That ownership is what makes the loop run.

There is also a feedback effect on the founder. Shipping to main on a public repo forces a different discipline than shipping to a preview URL. The commit message becomes the changelog. The PR description becomes the spec. The issue tracker becomes the roadmap. The product is the artifact you keep.

What to actually post

Most build-in-public threads I see post the wrong shape. They post screenshots when they should post links, and they post links when they should post diffs. The shape that works:

• Daily: one commit hash, one sentence on what shipped. Plain text. No hero image.
• Weekly: one PR link, one paragraph on what got merged and what got cut.
• Monthly: a README diff or a milestone issue, with a list of what is now possible.

## Daily
- commit hash
- one sentence

## Weekly
- one PR link
- what merged, what got cut

## Monthly
- README diff or milestone issue

The rule is: link to the artifact whenever you can. The artifact is what survives. For tools that don't fit a git-shaped workflow — design files, marketing pages, that kind of thing — fine, screenshot those. But for the part of the work that produces code, the repo is the thread. Everything else is filler.

Where sandbox tools fit

To be fair to the Lovables and Bolts and v0s of the world — they are good at one specific thing: collapsing the distance between idea and first render. For a founder whose bottleneck is "I don't even have a UI yet," that is a real gift. Use them.

The mistake is stopping there. A sandbox session is a sketch, not a product. The week you spend in a sandbox getting the first version of the UI right is the week you should be planning the export. Where does the code live after the sandbox? Who owns it? How do you get from "preview URL" to "I can git clone this on a fresh laptop and it runs"?

That handoff is the build-in-public moment. The sandbox is what got you to the first commit. The owned repo is what makes the rest of the thread worth reading.

Ship the kit, not the screenshot

This is the part where OTF shows up, because it's the part where most founders stall. The owned repo needs a starting point. A founder who is going to spend a year on a build-in-public thread wants to spend that year on their product, not on the parts of the stack that have already been solved.

OTF ships those starting points. The free MIT SDK on npm — @otfdashkit/ui, @otfdashkit/ui-native, @otfdashkit/tokens — gives a founder ~200 components that render the same on web, iOS, and Android from one codebase. You write <Button> once and it ships everywhere. The tokens flip one theme across both surfaces so the component is visually identical on every platform.

The paid kits — SaaS Dashboard, Fitness, Booking, all $99 — are full-stack, owned repos: auth, billing, DB, Stripe wired, deployable from one script. You own the code. You commit on day one to a repo you control. The Everything Bundle is $149.

Every kit ships the AI-tool configs (CLAUDE.md, .cursorrules, and 20+ tested prompts under ai/prompts/) so a coding agent extends the kit instead of regenerating it — which is what makes a build-in-public thread sustainable. You are not fighting your tools to keep up with your own project.

The ship-to-production script wires a custom domain, DNS, TLS, and a mobile build in one run. The 24-item design checklist is enforced by a script before any kit ships, so the parts that would embarrass you on day one are caught on day zero.

Live demos: saas.otf-kit.dev for the web stack, fitness-preview.otf-kit.dev for the mobile stack. Engineer-honest, no hype.

What this enables

A build-in-public thread anchored by an owned repo and a real component library does three things a screenshot thread cannot:

1. It survives the launch. The repo is the thread. The thread keeps generating trust after the initial launch wave is gone.
2. It recruits collaborators. People who can clone, run, and PR are a different population than people who can react to a screenshot.
3. It compounds. Each commit is the next paragraph. The README grows. The issue tracker becomes the roadmap. The marketing channel becomes the product.

The sandbox is where the first paragraph gets written. The repo is where the rest of the book lives.

The closing

Build-in-public is a long game. Screenshots are the short game. They both work — for about a week. After that, the receipts are what matter, and the receipts live in a repo you own, with commits you can link to, in a thread a reader can walk through.

Ship the repo. Link the commits. Skip the screenshots.