DEV Community

Cover image for I had a blog with no pipeline feeding it
Joseph Soper for BezaCore Labs

Posted on • Originally published at bezacore.com

I had a blog with no pipeline feeding it

Building in public is part of how this studio is supposed to work. It's in the go-to-market plan in plain language: don't buy attention, earn it by showing the work.

Then I shipped this blog, wrote two posts about how I run engagements, and noticed something uncomfortable. There was a publishing surface and there was plenty of real work happening behind it — two products in flight, a homelab platform, a client site — and absolutely nothing connecting the two. No pipeline. No cadence. Just a good intention and an empty queue.

Intentions don't survive contact with a build day

The obvious fix is "write a post about what you did today." I've tried that version. It fails for a boring reason: at the end of a long build session, writing a polished post is a tax, and taxes get dodged. You skip one day, then a week, and then you're staring at a blank editor trying to reconstruct what you did on a Tuesday eleven days ago.

That reconstruction problem is the one that actually worried me. My words at the time were:

I don't want to be 70% done and trying to remember what I did on day X.

The interesting details — the bug that took three hours, the tradeoff you agonized over, the thing that surprised you — have a short shelf life. They're vivid the day they happen and gone by the weekend.

So the tax has to come off the writing, not off the remembering.

Capture daily, publish weekly

The system splits into two tiers that cost very different amounts.

The build-in-public pipeline: daily capture into a per-project build log, a weekly distill into one post, publish canonically to bezacore.com/blog, then syndicate full copies to LinkedIn, dev.to, and Medium.

Tier one is capture, and it's about a minute. At the end of any session that produced something real, I drop one to three raw bullets into a build log: what shipped, why it's interesting, and a link. Bullets, not prose. No editing, no audience in mind. If a session wasn't post-worthy, I write nothing — not everything is content, and pretending otherwise is how you end up publishing filler.

Tier two is the distill, once a week. I read the week's seeds, pick one angle, and write a single post from it. One post, one idea. The raw material is already sitting there with the details intact, so the writing session is actually writing instead of archaeology.

The split matters because it puts the expensive step on a schedule I can defend and the cheap step where the memory actually is.

The part I got wrong on day one

I built the capture layer as a single central file. Every project's seeds in one place. It lasted about a day before it felt wrong — I was recording each project's story outside the project, in a file that belonged to none of them.

The instinct was to flip: give every project its own log. But then the weekly distill has to go hunting across a dozen files to find out which ones changed this week.

Central or per-project looked like a real tradeoff, and it wasn't one. My notes live in Obsidian, which has a feature — Bases — that generates a live index from every file matching a query. So each project got its own build log at its own root, and one auto-generating view rolls all of them up, sorted by most recently touched. Locality and a single pane of glass, no maintenance, nothing to keep in sync.

The lesson generalizes past note-taking: when a design feels like it's forcing a choice, check whether something already in your stack dissolves the choice before you spend an afternoon defending one side of it.

Make the habit structural

The last piece is the one that decides whether any of this survives past week three. I already run a scripted wrap-up ritual at the end of every session — update the roadmap, sync the work tracker, write the journal. The build-log capture is now a step inside it.

That's the whole trick. It isn't willpower or a calendar reminder. It's a step in a checklist I was already running, positioned at the exact moment the material is freshest. Habits that depend on remembering to have them are not habits.

Write once, publish everywhere

Because the expensive part is the thinking, not the typing, one post should reach more than one audience. This blog is canonical — it's the surface I own, and it's where the SEO accrues. From there the same post goes out as a full copy to developer communities with a canonical tag pointing home, and as native text on LinkedIn, where external links get suppressed so the link lives in the first comment instead. A short thread on X and Bluesky gets added once the weekly rhythm is real, rather than stalling the habit on format-wrangling before there's anything to wrangle.

Same idea, four surfaces, one writing session.


This post is the system's first output

There's a certain amount of nerve required to make post one an explanation of how you're going to write posts. But it's the honest starting point, and it's the piece that stops being true the longer I wait to publish it.

Build in public fails as an intention. It works as a system.

Top comments (0)