Skip to main content

Why I Build in Public

· 3 min read
Developer

A year ago I started sharing my revenue numbers, my mistakes, and my half-finished ideas on Twitter. Here's what I got from it — and the parts that surprised me.

What "building in public" actually means

It doesn't mean narrating every line of code you write. It means sharing the things that are actually useful to other people: what you shipped, what you learned, what broke, what the numbers look like.

The bar I try to clear: would I have found this useful two years ago?

The benefits I expected

Distribution. Sharing what you're building creates surface area. People can stumble across it. They can share it. If what you share is genuinely useful, it compounds.

This worked. My newsletter grew almost entirely through Twitter. Patchwork has customers who found me through a thread I wrote about database schema design — not a thread about Patchwork.

Accountability. Saying publicly that you're going to ship something by Friday makes you more likely to ship it by Friday. This also worked, mostly.

The benefits I didn't expect

Customers who trust you before they pay. Several customers mentioned they'd followed me for months before buying. They'd watched me respond to bug reports, fix things quickly, write honestly about problems. By the time they decided to pay, they weren't taking a risk — they already knew how I operated.

This is worth more than any marketing campaign.

Feedback loops that improve the product. When I wrote about Patchwork's onboarding being confusing, three readers replied with specific suggestions. Two of them were excellent. I shipped both within a week. Neither would have occurred to me on my own.

Connections that matter. I've met other developers through public building who I now talk to weekly. One introduced me to a customer who accounts for $300 MRR. The relationships aren't transactional — they're genuine — but they have had real business value.

The costs

Time. Writing takes time. A good Twitter thread takes 45 minutes. A newsletter issue takes two hours. This is real.

Being wrong in public. I've made predictions that didn't pan out. I've shared metrics that looked worse the following month. Some people point this out.

This is fine. Being wrong in public, and then being honest about it, is actually more credible than only sharing the wins.

The comparison trap. Following other developers closely means watching some of them grow faster than you. This can be motivating or demoralizing depending on the day.

What I'd tell someone starting out

Don't wait until you have something impressive to share. The most useful thing you can share is the thing you figured out this week that you didn't know last week. That's accessible. That's relatable. That's what people will share with someone who needs it.

Revenue milestones are fine to share. Learning moments are more valuable.

Start small. One tweet. One short post. See what happens.