How to Build in Public: Sharing Your Learning Without Oversharing

TL;DR - Building in public means sharing your process, not performing it. The goal is a trail of evidence, not an audience. - Brief, specific updates work better than long-form content for ongoing projects. - The format that works: "I'm building X to solve Y. Here's where I am today." - There is a clear line between sharing work in progress and venting about rejection in real time. One helps. The other doesn't. - You do not need to become a content creator. Occasional, honest updates are enough.

"Build in public" has become a loaded phrase. It conjures images of developers who tweet every commit, post daily progress updates, and have turned their job search into a content strategy. That version exists, and it is not what this is about.

The version worth considering is quieter. It means sharing your process in a way that leaves a visible record of your thinking, your projects, and your growth. Not as performance, but as documentation. The audience is secondary. The trail is primary.

That trail is what makes building in public useful for a job search. A hiring manager who looks at your GitHub and sees a project with commits over three months, supplemented by a few LinkedIn posts about decisions you made along the way, has a more complete picture of you than someone whose portfolio is a finished product with no context.

What "process" actually means

Outcomes are easy to share. You finished a project, you deployed something, you passed a coding challenge. Those are events.

Process is everything in between. The decision to use one library instead of another. The refactor you did after realizing your initial approach was making the code harder to read. The bug that took longer than it should have and what you learned from it. The feature you scoped out of the MVP because you ran out of time and had to make a judgment call.

None of that shows up in a finished GitHub repository. The commits are there, but the reasoning is not. Sharing process means occasionally adding the reasoning to the public record.

This does not require daily posts. One update when you start a project, one or two in the middle when something interesting happens, and one when you finish. That is three to five posts over the course of a project. It is not a content strategy. It is documentation with a small audience.

The format that works

The most effective format for a build-in-public update is specific and grounded.

"I'm building [X] to solve [Y]. This week I ran into [specific problem]. I approached it by [thing you tried]. Here's where I landed."

That is it. The specificity is what makes it useful and what makes it readable. Vague updates ("making progress on my project, feeling good about it") communicate nothing. Specific updates ("I spent two days trying to get the authentication flow right with JWT and finally switched to session-based auth because it was simpler for the scope of this project") communicate a lot.

The "I'm building X to solve Y" framing is worth paying attention to. "Y" is the reason the project exists. If you built a tool because you kept manually doing something that should be automated, that reason is more interesting than the tool itself. It tells a reader that you notice problems, you think about solutions, and you build things. Those are the things a hiring manager wants to see evidence of.

Brief updates versus long-form posts

For ongoing projects, brief updates are better than long-form posts. A long-form post is appropriate when a project is finished and you are writing a retrospective. While the project is in progress, a few sentences or a short paragraph is the right format.

Brief updates are lower friction to write, which means you are more likely to actually write them. They are easier to read, which means more people will read them. And they feel more honest, because they match the state of the work. A project that is not done yet should not have a polished summary.

The platforms where brief updates work are LinkedIn and, if you use it, Twitter/X. A LinkedIn post with a screenshot and three sentences about a decision you made is a legitimate update. It does not need an introduction, a conclusion, or a list of lessons learned.

LinkedIn posting for developers covers the specific mechanics of what lands well on LinkedIn and what does not. The principles from that article apply directly to build-in-public updates on the platform.

What to share and what to keep private

There is a useful distinction between sharing work in progress and sharing feelings about the work.

Work in progress is fine to share. You are figuring something out. The approach might change. The project might go in a different direction. That is all normal and expected, and readers who have built things know it. A post that says "I thought I would implement this with X, but I'm starting to think Y is a better fit" is honest and interesting.

Feelings about the work become complicated when they are negative. Frustration with the job search, discouragement after rejections, venting about companies that ghosted you after three interviews. These are all understandable reactions. They are also the kinds of posts that can create a first impression you do not want. Hiring managers and recruiters scroll LinkedIn. If the first thing they see from you is a post about how broken the interview process is, that is the frame they bring to your application.

This is not about suppressing honest feelings. It is about choosing the venue. Private conversations with friends, support communities, and therapy are appropriate places for processing the emotional side of a job search. Public posts are appropriate for the work.

The difference between building in public and becoming a content creator

Developers who try building in public and then stop usually hit the same wall: it starts to feel like a second job.

The version that does not feel like a second job is one that stays attached to the work rather than becoming independent of it. When you build in public to support your actual work, the updates write themselves. You made a decision. You write about it. You solved a problem. You share how. You finished something. You post a brief note.

When building in public becomes its own activity, disconnected from the work, it starts to feel like you are writing content about building rather than building. That is when it becomes unsustainable and, often, when it starts to feel performative.

The test is simple: if you are spending more time on the update than on the work it is describing, the proportion is wrong. An update should take ten minutes to write. The work should take hours. If that ratio inverts, you are no longer building in public. You are just content creating with a technical theme.

How it connects to your portfolio

Build-in-public updates function as a real-time portfolio supplement. Your portfolio projects show what you built. The updates show how you built it and what you were thinking along the way.

A hiring manager who looks at your LinkedIn profile and sees a project they recognize from your portfolio, with a few posts scattered over several months showing your decisions and progress, gets a level of context that a portfolio alone cannot provide. They see that the project took real time and involved real decisions. They see how you communicate about technical work. They see that you were intentional rather than just following a tutorial.

This is also why the updates should be about decisions and problems, not just milestones. "I just pushed the v1 of my project" is less interesting than "I decided to scope the project down significantly after realizing the full version would take three more months to build. Here's what the MVP does and why I think those are the right features to start with." The second version reveals judgment. The first just reveals completion.

Handling setbacks publicly

One of the harder questions in building in public is how to handle things that do not go well. A project that stalls. An approach that did not work. A feature you had to cut.

These are worth sharing, with the right framing. The framing that works is retrospective and learning-oriented: "I tried X, it did not work because of Y, and here's what I am doing instead." That is honest, specific, and shows resilience rather than just failure.

What does not work is real-time despair. There is a difference between "I have been stuck on this bug for two days and I'm starting to think I need to rethink my approach" and "I've been stuck on this for two days and it's driving me insane, I don't know why I thought I could do this." The first is relatable. The second creates a different impression.

The rule of thumb: share the problem after you have at least a theory about the solution. That keeps the narrative moving forward rather than leaving it in an unresolved, distressed state.

Building in public and your broader online presence

Building in public is one piece of a broader online presence. Writing online as a developer explains how a body of writing and occasional posts work together to create a findable, readable record of your thinking. Personal branding for software engineers covers how all the pieces, your portfolio, your GitHub, your writing, and your social presence, form a coherent picture.

Building in public is the most informal and most ongoing of these activities. It does not require the structure of a blog post or the completeness of a portfolio project. It is the conversational layer on top of the more formal artifacts. Used well, it makes those artifacts feel more alive and gives people reasons to visit them.

Starting with one project

The practical way to start is to pick one project you are currently working on or about to start, and commit to sharing three updates over the course of it.

One update at the beginning: what you are building, why, and your initial approach. One update in the middle: something you encountered that was interesting, a decision you made, or a problem you solved. One update at the end: what you built, what you would do differently, and where it lives.

Three posts. One project. That is the minimum viable version of building in public. It is achievable without becoming a habit you have to maintain, and it gives you a concrete example of the format before you decide whether to do more.

If those three posts come naturally and you find yourself wanting to share more, expand from there. If they feel forced, you have still created three pieces of visible work that did not exist before.

Related reading: writing online as a developer covers the longer-form side of sharing your learning online. For deciding what project to build in public with, how to pick a portfolio project helps you find a project worth investing the time and visibility in.

If you want structured support with the job search, portfolio, and visibility strategy, here's how the Globally Scoped program works.