How to build in public as a solo developer with a day job

By Naod Tadele · November 5, 2026 · 6 min read

Most build in public advice is written by people who build full time. They post several times a day, reply to everyone, and ship something new every week. If you code your side project after work and on weekends, that pace is not a plan. It's a way to burn out by month two.

The good news: you don't need that pace. A side project with a steady, honest trail of posts beats a burst of daily updates that stops after three weeks. This guide is a system built for people with a few hours a week.

Accept the real constraint

Your scarce resource is not ideas. It's hours. Every minute spent writing a post is a minute not spent on the product. So the goal is not to post more. The goal is to make posting nearly free.

That means three rules:

• Posting should never need a separate work session.
• Every post should come from work you already did.
• Missing a week should not break anything.

Pick a rhythm you can keep on a bad week

Choose a cadence based on your worst week, not your best one. For most people with a day job, that looks like:

1. One update post about what you shipped or learned that week.
2. One or two small posts during the week: a screenshot, a bug you fixed, a question for your audience.
3. Replies when you have five minutes, on posts from people in your niche.

That's it. Three posts a week, every week, adds up to a real record over a few months. If you want more detail on frequency, read how often to post when building in public.

Turn your session notes into posts

The cheapest source of posts is the work itself. At the end of each coding session, write one line in a notes file or your commit message about what changed and why. Those lines become your posts.

Notice what this post does. It says what shipped, admits the effort, and explains why it matters. It took two minutes because the session already happened.

Good commit messages help here too. "Fix grouping" is useless later. "Group alerts by deploy id instead of time window" is a post waiting to be written. More on that in how to turn GitHub commits into posts.

Make the slow pace part of the story

People with day jobs often hide it, as if building at night is less serious. It's the opposite. Many of your readers are in the same spot, and they relate to it.

You don't have to apologize for slow weeks. Just say what you did. Consistency reads as commitment even when each step is small.

Batch the writing, schedule the posting

Writing posts in the moment is what makes posting feel expensive. Instead, write a few at once and let a queue handle timing.

• On your weekly slot, draft the update plus two small posts.
• Schedule them across the week at times your audience is around.
• During the week, you only reply. No writing from scratch.

It also keeps posting out of your work hours.

Protect your day job

This part is not optional. Before you post about a side project:

• Read your employment contract. Some have clauses about outside work or intellectual property. If anything is unclear, ask someone qualified.
• Never use work hardware, accounts or time for the side project or for posting about it.
• Never share anything from your employer: code, internal tools, customer names, or problems you only know about from work.
• Keep it separate. If your project is close to your employer's business, think hard about whether to build it in public at all.

Building in public is a choice. If the risk to your job is real, build quietly for now. You can always share the story later.

Handle the quiet weeks

Some weeks you won't touch the code at all. You can still post a lesson from earlier in the build, a decision you're stuck on, or what you plan to build next. This list of build in public post ideas has more starting points.

What not to do

• Don't promise dates. "Launching next Friday" is risky when your evenings aren't yours to plan.
• Don't compare your pace to full time founders. Their week has 40 more hours in it.
• Don't post at work. Even a quick post during work hours can look bad, and it pulls your focus.
• Don't stop when you miss a week. Post the next update as if nothing happened. Nobody keeps score as closely as you do.

How Loudcode helps

The hardest part with a day job is turning a tired evening of coding into a post. Loudcode reads your GitHub commits, pull requests and releases and drafts build in public posts in your voice. A weekly 30-second check-in plans the week's posts, Ideas fills in quiet weeks, and the queue spreads posts across posting times you choose. If you code with Claude Code, Codex or Cursor, you can ask it to "post about what we just shipped" through the MCP server before you close the laptop. Every post waits for your approval before it goes to X.