Building in public needs systems, not motivation

There's a version of building in public that looks like this: a founder tweets their MRR every Monday, ships something every Friday, and somehow maintains momentum across a full-time job, a product, and a life.

You watch it and wonder what they know that you don't.

Usually the answer isn't motivation. It's systems.

Motivation is the wrong thing to rely on

Motivation is tied to energy, mood, and circumstance. It spikes when you launch something and people respond. It disappears when you're three weeks into a bug that shouldn't exist, work is demanding, and you haven't shipped anything visible in a fortnight.

If your project only moves when you feel inspired, it will stall the moment real life gets in the way. And real life always gets in the way.

The founders who ship consistently — not the ones who sprint and burn, but the ones who are still building two years later — aren't more motivated. They've just stopped relying on it.

What a system actually looks like

A system for a side project doesn't need to be complicated. It needs to answer three questions without you having to think:

What am I working on next? A maintained backlog with clear, small tasks. Not "rebuild the dashboard" — that's a project. "Fix the broken hover state on the pricing toggle" — that's a task. The difference matters at 9pm when you have 40 minutes and limited cognitive bandwidth.

When am I working on it? Protect specific time rather than working in whatever gaps appear. Gaps don't appear consistently. For me it's weekday evenings after the kids are in bed and weekend mornings. Those windows are fixed. The work fits inside them.

What does done look like today? Narrow your definition of done to something achievable in a single session. Ship the small thing. The small things compound.

The trap of public pressure without private structure

Building in public creates useful external accountability. When you've told people what you're working on, there's a social pressure to follow through. That pressure can pull you to your desk on a night when motivation alone wouldn't.

But public pressure only works if there's a system underneath it. Without one, the accountability becomes anxiety. You're behind on something vague, with no clear path to catching up, and the public updates start to feel like a debt you can't repay.

The sequence matters: system first, then go public. Not the other way around.

The specific things that help when you're building alongside a full-time job

I've been building Clubase and PostHacker alongside a senior engineering role at Sourceful. There's no secret to it, but a few things make the difference:

A weekly reset. Every Sunday I spend 15 minutes looking at what moved last week and picking the three things I want to move this week. Not ten things. Three. This prevents the backlog from becoming a source of guilt.

Momentum tasks alongside hard tasks. When the energy is low, don't tackle the hardest thing. Have smaller tasks available that still move the project forward. Fixing copy, improving a UI state, writing a post. These keep the habit alive on the days when deep work isn't available.

Version control as a progress log. Committing regularly — even small commits — creates a visible record of movement. On the days when nothing feels like enough, the commit history tells a different story.

Separating thinking from building. Some sessions are for writing code. Some are for thinking about what to build next. Mixing the two in a 45-minute window leads to neither happening well.

What building in public is actually for

The public part of building in public is often misunderstood. It's not primarily a marketing strategy. It's not about follower counts or going viral with a revenue screenshot.

The most useful thing it does is force clarity. When you have to explain what you're building and why, you understand it better yourself. The act of writing a weekly update reveals whether you actually moved the thing forward or just stayed busy.

That clarity feeds back into the system. You update the backlog, adjust the priorities, and go again.

The honest version

Most side projects die not because the idea was bad, but because the founder ran out of steam before they found out. The idea never got a fair test because it was always competing with everything else in a life that didn't have a system to protect it.

Building in public is worth doing. But only once you've answered the private question first: how does this project stay alive when the motivation disappears?

If you can answer that, the public part takes care of itself.