·Day 22 · building git-to-market in public

This week: post gates, clearer LinkedIn dry-run previews

This week I focused on two things that directly reduce friction for makers: smarter post gates so you only publish the commits you mean to, and clearer LinkedIn dry-run previews so you can check truthfulness before anything posts. Both changes trim the manual review work and lower the risk of accidental or misleading posts.

What shipped

  • Post gating rules that stop drafts, WIP commits, and private notes from becoming public posts automatically. You can still opt in per-commit, but the default now errs on the side of not posting anything you likely didn’t intend to share.
  • LinkedIn dry-run mode that generates the exact preview text and image attachments you’d see on LinkedIn without sending anything. It highlights where the preview might truncate or replace content so you can fix wording before it goes live.
  • Better error surfacing when a post fails to publish. Instead of a silent failure or a vague log entry, you get a clear reason and the specific commit attached so you can decide whether to retry or skip.

Why it matters

  • Less manual policing: makers told me they were spending time filtering which commits should be public. The post gates reduce those decisions by applying conservative defaults and making opt-ins explicit.
  • Safer LinkedIn posts: LinkedIn’s preview quirks (truncation, image selection, link text) have caused misleading snippets. The dry-run puts the final preview in front of you so you can adjust commit messages or images before anything posts.
  • Faster recovery from failures: when a network or API error prevented a post, it used to be hard to find which commit failed. Clear errors mean you can retry only what matters and keep your daily rhythm intact.

How this will change your weekly flow

  • Fewer surprises: expect fewer accidental posts and less low-value noise in your channels. If you rely on the default behavior, you’ll see fewer drafts published automatically.
  • Faster approval decisions: use the dry-run preview to quickly confirm a high-impact post. If it looks good in dry-run, you can confidently publish knowing the public preview matches your intent.
  • Less time spent debugging: when something does fail, the UI will point you to the failure reason and the commit so you don’t hunt through logs.

What's next

  • I’ll add a small UI to whitelist files or folders (so commits touching docs vs. code can be treated differently). That helps teams who want documentation changes public but code changes private by default.
  • I’m also planning a simple audit trail for published posts so you can see which commit produced which social update and quickly revert if needed.

Related reading

[This week: clearer LinkedIn previews and smarter post gates: )

[This week: clearer LinkedIn previews and smarter post gates: )

[This week: better post gates and clearer LinkedIn previews: )

Watch git-to-market ship, day by day

1 person is following the build

This week: post gates, clearer LinkedIn dry-run previews —…