Build-in-Public Content Pipeline: Solo Founder Guide (2026)

Last Tuesday at 11pm I realized I hadn't posted a build-in-public update in three weeks. Not because nothing happened — we shipped two features, broke production twice, and figured out why our Stripe webhooks were failing silently. Plenty of material. I just... forgot. Again.

Classic.

That's the problem with build-in-public. It's not a content strategy problem. It's a systems problem. And I say that as someone who's made this exact mistake across multiple products. Embarrassing? Sure. But at least now I've built something that works.

This tutorial walks through the content pipeline I finally got running. Topic capture → draft → publish → social distribution. Four stages, minimal tooling, zero excuses. By the end you'll have a working workflow that actually runs — not a Notion template you'll abandon in two weeks. (I've abandoned at least four of those myself.)

What We're Building

A personal content pipeline for build-in-public updates. Not a multi-agent system. Not a content factory. Just a reliable way to capture what happened, turn it into a post, publish it, and share it.

You'll have:

• A capture system that grabs topics as they happen
• A drafting workflow with a forcing function (because "I'll write it later" is a lie)
• An automated publish step that doesn't require you to remember passwords
• Social cross-posting that runs while you sleep

Total setup: under 2 hours. Ongoing time: 30 minutes per post, give or take. This isn't about scaling content. It's about showing up consistently. That's it. Nothing fancy.

Prerequisites

Before starting:

• A blog or publishing destination — your own site, Substack, Ghost, whatever. If you don't have one, start with Substack. Free, takes 5 minutes.
• A notes app you actually use — Notion, Obsidian, Apple Notes, a text file. Don't switch tools. Use what's already in your workflow.
• GitHub account — for the automation bits. Free tier works fine.
• Node.js 18+ — if you want the optional scheduling scripts
• 30 minutes of focused time — close Slack, silence Slack, and honestly maybe just delete Slack

No fancy tools required. We're building on stuff you already have.

Step 1: Set Up Topic Capture

The biggest failure mode isn't writing. It's forgetting what to write about. Something happens Thursday. You think "that's a good BIP topic." Monday arrives and you're staring at a blank page.

Fix this with a dedicated capture point. One place. Always accessible.

Option A: Notion database

Create a database called "BIP Topics" with these fields:

Field	Type	Notes
Topic	Title	One-liner description
Date happened	Date	When it occurred, not when you logged it
Category	Select	Win / Struggle / Learning / Decision
Raw notes	Text	Messy details, screenshots, links
Used	Checkbox	For filtering published topics

The category field matters more than you think. A week of only "wins" reads as bragging. A week of only "struggles" reads as doom-scrolling. Mix it up.

Option B: Obsidian daily note

Add a ## BIP Topics section to your daily note template. Every time something happens, add a bullet. At the end of the week, you have 5-15 potential topics without trying.

Option C: Voice memo → transcript

Talk into your phone for 30 seconds. "Just deployed the new pricing page. Took three tries because Stripe's webhook format changed. Lesson: always check their changelog before touching billing code." Use Whisper or your phone's native transcription. Paste the transcript into your capture system.

I use Option C more than I expected to. Walking to get coffee is prime topic-capture time. The topics you catch in motion are usually better than the ones you sit down to brainstorm.

Honestly, brainstorming sessions for BIP topics feel forced. The good stuff happens when you're not trying.

Step 2: Create Your Drafting Workflow

Here's the uncomfortable truth: you need a forcing function. "I'll write when I feel like it" produces nothing. "I write every Tuesday at 9am" produces content.

The Weekly Ritual

Pick a day. Pick a time. Block 45 minutes. Same slot every week.

Mine is Tuesday 9am. Non-negotiable. Calendar block is labeled "BIP Post — no meetings." Anyone who books over it gets a polite "no."

The Template

Every post follows the same shape:

# [Week of DATE] — [ONE THING IN 5 WORDS]

## What happened
[2-3 paragraphs. Specifics. What you shipped, broke, learned, decided.]

## Why it matters
[1-2 paragraphs. The takeaway. What changed because of this.]

## What's next
[2-3 sentences. What you're working on. Creates continuity.]

---
Building [PRODUCT] in public. [LINK]

That's it. No fancy format. The constraint is the point. You don't have to decide how to write — just fill in the blanks.

First Draft Rules

• Write ugly. Edit later. Or don't edit at all — raw is fine for BIP.
• Set a timer for 25 minutes. Publish whatever exists when it goes off.
• If you're stuck, start with "This week I..." and keep typing.

I've published posts that were basically bullet points. Nobody complained. The bar for BIP is "interesting and honest," not "polished and perfect."

My worst-performing posts? The ones I spent hours on. Go figure.

Step 3: Automate the Build-in-Public Publish Step

Manual publishing is where pipelines die. You finish the draft. You open the CMS. You need to log in. You forgot your password. You reset it. You get distracted by something else in your email. Draft sits unpublished for three days.

Option A: Git-based publishing

If your blog is static (Next.js, Astro, Hugo), publishing is a git push. Write your post as a markdown file, commit, push.

# Assumes posts live in content/blog/
git add content/blog/bip-week-of-2026-06-17.md
git commit -m "BIP update: pricing page deploy"
git push origin main

Your CI/CD handles the rest. Railway rebuilds in under 60 seconds for most static sites. If you're evaluating hosting, we compared options in our Railway vs Vercel breakdown.

Option B: API-based publishing

Substack, Ghost, and most CMSes have APIs. Write a 20-line script that posts markdown via API.

const publish = async (title, content) => {
  const res = await fetch('https://your-cms.com/api/posts', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.CMS_TOKEN}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ title, content, status: 'published' })
  });
  return res.json();
};

Put this in your repo. Run it after writing. One command = published.

Option C: Scheduled publish via GitHub Actions

For maximum laziness, write your post as a PR. GitHub Action publishes it when merged. If you're using AI agents to help with development, we covered integrating agents with CI/CD pipelines in detail.

# .github/workflows/publish-bip.yml
name: Publish BIP Post
on:
  push:
    branches: [main]
    paths: ['content/bip/**']

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: node scripts/publish-bip.js
        env:
          CMS_TOKEN: ${{ secrets.CMS_TOKEN }}

Now merging a PR = publishing the post. The PR itself is your review step. Want feedback before publishing? Ask someone to review the PR. Want to schedule ahead? Draft the PR and merge it on Tuesday.

This approach felt over-engineered at first. It's not. The friction of "open CMS, log in, paste content" killed more posts than I want to admit.

Step 4: Wire Up Social Distribution

Your post exists. Now it needs to reach people. Manual cross-posting is tedious and you'll skip it. Automate or accept that you won't do it.

Option A: RSS → Buffer/Typefully

Most blogs generate RSS. Feed it to Buffer, Typefully, or similar. They'll auto-draft social posts when new content appears.

Buffer costs $15/mo for the features you need. Typefully has a free tier that works for low volume. Both let you edit before posting — important because auto-generated tweets are usually terrible.

Option B: IFTTT / Zapier trigger

"When new RSS item, create draft tweet with title + link." Free tier of either platform handles this. Runs within minutes of publishing.

Option C: Custom cron job

For full control, write a script that runs hourly:

// check-and-post.js
const Parser = require('rss-parser');
const Twit = require('twit');

const parser = new Parser();
const twitter = new Twit({
  consumer_key: process.env.TW_KEY,
  consumer_secret: process.env.TW_SECRET,
  access_token: process.env.TW_TOKEN,
  access_token_secret: process.env.TW_TOKEN_SECRET,
});

(async () => {
  const feed = await parser.parseURL('https://yourblog.com/rss');
  const latest = feed.items[0];

  // Check if already posted (track in a file or DB)
  if (alreadyPosted(latest.guid)) return;

  await twitter.post('statuses/update', {
    status: `${latest.title}\n\n${latest.link}`
  });

  markAsPosted(latest.guid);
})();

Run via cron or Railway's cron service. Check once per hour. Post when there's something new. Done.

The key: don't require yourself to remember. If posting requires manual steps, it becomes optional. Make it automatic or make it one command.

I'm not disciplined. I'm lazy with good systems. Big difference. That's the context engineering mindset — set up systems that do the thinking for you.

Common Errors and How to Fix Them

Error: Posts sit in draft for days

You don't have a forcing function. Fix it: add a calendar block. Treat it like a meeting. If Tuesday 9am passes and you didn't post, you failed the meeting — acknowledge it, don't just reschedule indefinitely.

Error: Running out of topics

You're not capturing consistently. Fix it: lower the bar for what counts as a topic. "Changed button color" is a valid BIP topic. You don't need breakthroughs every week. Small updates are fine.

Error: Social posts get no engagement

The default "New post: [title] [link]" format is invisible. Fix it: write a hook sentence. Not "New post about our pricing launch" but "Spent 14 hours on a Stripe integration that should've taken 2. Here's what went wrong." Pull out the interesting bit.

Error: Pipeline feels like a chore

You're over-engineering it. Simplify. If Notion + manual publish + one tweet works, that's the pipeline. Don't add automation until something actually breaks.

I had a 7-step workflow once. Lasted two weeks. Now it's three steps. Learn from my mistakes.

Next Steps

You've got the system. Now it needs to run.

Week 1: Set up capture. Pick your tool. Start logging topics.

Week 2: Do one full cycle manually. Write, publish, post to social. Note what's annoying.

Week 3: Automate the annoying bits. Probably publishing and cross-posting.

Week 4: Evaluate. Did you post every week? If not, where did it break? Fix that specific failure point.

The pipeline will evolve. Ours has changed three times this year. The current version is way simpler than the first one — we kept removing steps that weren't pulling weight.

If you're tracking what's working (and you should be), JustAnalytics gives you cookieless analytics in an under-5KB script. For email sequences triggered by content, JustEmails runs at a flat $49/year for unlimited domains and mailboxes. And if you're documenting coding decisions along the way, DevOS is where we're building agent-assisted project management — waitlist is open.

Look — the hardest part of build-in-public isn't the content. It's the consistency. A pipeline doesn't make you a better writer. It just removes the excuses. Removing excuses is 80% of the work.

Frequently Asked Questions

How often should I publish build-in-public updates?

Weekly is the sweet spot for most solo founders. Daily burns you out. Monthly lets momentum die. We ship a BIP update every Tuesday — same day, same time. Consistency beats frequency. Your audience learns when to expect you. Pick a cadence you can sustain for 6 months, not one that sounds impressive for 2 weeks.

What should I include in a build-in-public post?

One thing that happened, one thing you learned, one thing coming next. That's the minimum viable BIP post. Revenue screenshots are optional. Struggles are more interesting than wins — people connect with the mess. Don't polish it. The whole point is showing the work, not a highlight reel.

Can I automate build-in-public content completely?

Parts of it, not all of it. Automate the boring stuff: topic tracking, scheduling, cross-posting. Keep the writing human. Your voice is the product. We automate topic capture and social distribution but write every post manually. Automation handles logistics. You handle insights.

What tools do I need for a BIP content pipeline?

A capture system (Notion, Obsidian, Apple Notes), a publishing destination (blog, Substack, Twitter), and a scheduler (cron job, Buffer, manual). That's it. Start with three tools max. Add complexity only when something breaks. Most founders over-tool and under-publish.

---

Follow the Studio

Velocity Digital Labs is a multi-product studio building 8 active SaaS products with a 1-founder + 1-manager structure. Bootstrapped. No VC platform-play — just shipping.

See the products → · Browse all VDL blog posts