FREE RESOURCE

How to build in public

Building in public means sharing the work as you do it: wins, misses, decisions, and the boring middle. You leave a trail other founders can follow. You do not wait for a polished launch-day announcement.

I have been doing this for years on X (@thisiskp_), in my newsletter, and on this site. Roles at On Deck, Paddle, and Netlify showed up because people could already see how I think and ship. Mathias Biilmann followed my posts for months before I joined Netlify to lead community. That is luck surface area in practice.

Why it works for founders

Most early customers, collaborators, and early hires do not find you through a cold pitch. They find a trail of specific work: a bug you fixed, a pricing change you explained, a failed experiment you documented.

When you publish that trail:

• People learn what you care about before they ever talk to you.
• Feedback arrives while you can still change the product.
• Trust compounds from showing up for years. A cloned landing page will not give you that.

I wrote more on the "100 reps" version of this in The Price of Greatness Is 100 Reps. Short version: joy over ROI keeps you posting through the quiet stretch when nobody is watching yet.

Building in public is also a filter. If you are scared to say what you are building, you may be solving a problem you do not understand well enough to explain. Writing the update often clarifies the product.

How to start (practical steps)

You do not need a big audience. You need a cadence.

1. Pick one channel and stick to it for 30 days. X works for me. A weekly newsletter, LinkedIn, or a simple public changelog can work too. Switching platforms every week kills the habit.
2. Write to express, not impress. Share one lesson or insight from the day. Document the learning first. You will notice what others find useful and double down later. I covered this for newbies in Building in public advice for newbies.
3. Ship a small public artifact each week. A screenshot, a short Loom, a changelog, a "what I tried and what broke" note. Variety beats a dry daily status tweet. When I only posted daily updates, I quit. Formats matter. See 8 unique ways to build in public.
4. Reply more than you broadcast at the start. Leave useful comments under people you admire. Contribute tips and examples. Social capital comes before viral posts.
5. Create more, judge yourself less. Beginners often post 1–4 times a week because they fear looking foolish. Getting better takes more shots. Aim for a volume you can keep without burnout, then raise it.
6. Connect the dots in public. When something good happens (a hire, a customer, a job), say what led to it. People need to see the chain from "quiet post" to "real outcome."

If you want the fuller framework, start with The building blocks of building in public (part 1) and part 2.

What to share

Share things that help another founder make a better decision this week:

• What you shipped, and why
• Metrics that teach (MRR, signup rate, churn) when you are comfortable naming them
• Decisions and tradeoffs ("we cut this feature because…")
• Process: how you hired, priced, wrote the landing page, handled support
• Failures with a clear lesson, not a pity party
• Customer stories (with permission)
• Tools and workflows you actually use

Be specific. "Revenue is up" is weak. "Went from $2k to $4k MRR after cutting annual plans for new users" is useful.

What not to share

You can build in public without oversharing.

Skip:

• Private customer data, credentials, or anything under NDA
• Half-baked legal, fundraising, or partnership details that can blow up a deal
• Team drama and personal attacks
• Vague motivational fluff with no receipts
• Every half-finished idea (pick a lane so people know what you stand for)
• Competitor-bashing that does not teach anything

Building in public does not mean no privacy. It means the work is visible enough that strangers can learn from it and find you.

A simple weekly rhythm

If you want a default:

• Mon: one process note (what you are working on this week)
• Wed: one lesson or metric
• Fri: one artifact (demo, screenshot, changelog, or customer quote)

That is three posts. Enough to leave a trail. Light enough to keep for months.

Want templates? Grab the Build In Public Manual. Prefer slides? Open the Build In Public Deck.

FAQ

What is building in public?

Building in public means sharing the work as you do it: wins, misses, decisions, and the boring middle, so other people can follow the trail and give feedback while you can still change course.

Why should founders build in public?

It expands luck surface area. Customers, collaborators, and employers can see how you think before they talk to you. Feedback arrives earlier. Trust compounds in a way a cloned landing page cannot.

How do I start building in public with no audience?

Pick one channel for 30 days. Post small, specific updates. Reply helpfully under bigger accounts. Focus on lessons from your own work. Volume beats polish at the start.

What should I share when building in public?

Ship notes, decisions, metrics you are willing to name, customer stories (with permission), failures with lessons, and tools you actually use. Prefer specifics over slogans.

What should I not share?

Private customer data, NDA material, deal-breaking fundraising or legal details, team drama, and empty motivational posts with no evidence.

Is building in public the same as personal branding?

Personal branding is often about positioning. Building in public is a practice: you document real work over time. A brand can grow from that practice, but the reps are the point.

Do I have to share revenue and failures?

No. Share what you can stand behind. Revenue and failure stories help when they teach. Skip them when they put people at risk or break trust.