Building in public is one of those things that sounds great in theory — share your journey, grow an audience, get customers before you launch. And sometimes it genuinely works like that. But there's a version of building in public that's basically just a developer's Twitter performance, optimized for likes from other developers who are also building in public and not buying anything.
We've been doing this with peal.dev for a while now. We've posted wins, losses, embarrassing bugs, revenue numbers, and the occasional midnight deploy disaster. Here's what we actually learned — not the sanitized version.
What Actually Works
The stuff that works is almost always the stuff that's uncomfortable to share. Not the vague 'we hit a new milestone!' post, but the 'here's exactly what broke, why, and what it cost us' post. Those perform better, teach better, and build more genuine trust.
Showing your actual numbers — even small ones — works. We were hesitant to post revenue numbers when they were embarrassingly low. Then we did it anyway. Turns out, other devs in the same stage are hungry for reality checks. 'We made €340 in month two' is more useful to someone starting out than 'we hit 5 figures!' with no context.
- Specific technical problems you solved (with the actual code or config)
- Real revenue or traction numbers, even if they're small
- Mistakes and what they cost you in time or money
- Your decision-making process — why you chose X over Y
- Things you tried that flat-out didn't work
Technical build logs also punch above their weight. When we wrote about our specific approach to multi-tenant routing in Next.js, it got shared by people who had the same problem. Not because it was genius — because it was specific. Specificity is the whole game.
What Doesn't Work
Posting about posting. 'Excited to start building in public! Follow along for the journey!' is the developer equivalent of telling people you're going to the gym instead of going to the gym. Nobody cares about your intentions. Ship something first, then talk about it.
Engagement bait disguised as authenticity. You know the format: 'Quit my job 6 months ago. Here's what I learned: [thread]'. Sometimes these are genuine. A lot of the time they're optimized for virality, not information density. Readers can smell the difference.
Posting about your tech stack decisions in exhaustive detail when you haven't launched yet. We've seen developers post 15-part threads about why they chose Postgres over MySQL before writing a single line of product code. That's not building in public. That's procrastinating in public.
- Vague milestone posts ('something big is coming...')
- Follower count as a metric of success before you have customers
- Posting every day just to maintain cadence, regardless of whether you have something worth saying
- Dunking on competitors or similar products for engagement
- Inspirational quotes with your product name attached
The audience you build by posting consistently mediocre content is not the audience that will buy your product. It's an audience optimized for consuming mediocre content.
The Cringe Taxonomy
Let's be honest about the cringe, because it's everywhere and we've been guilty of some of it.
**The Humble Brag Revenue Post.** 'We almost gave up last month. Then this happened: [screenshot of Stripe dashboard showing €50k MRR].' The suffering narrative exists to make the number feel earned. Sometimes it's real. Often it's manufactured contrast. If your number is good, just post the number.
**The Founder Identity Collapse.** When everything you post becomes about being a founder, shipping, the grind, the hustle — you've stopped building in public and started performing Founder. Your product becomes secondary to your personal brand as someone who has a product. This is a trap that's particularly easy to fall into if you get early traction on social media.
**The Artificial Countdown.** 'Launching in 7 days! Follow for updates!' Cool. We'll see you in 7 days. Or 14. Or never, if the pressure gets too real and the product isn't ready. Artificial deadlines announced publicly have a way of creating anxiety without accountability.
**The Engagement Farmer.** Posting 'hot take: [thing that's not actually a hot take]' to generate replies. We've done this. It gets engagement. It doesn't build anything real.
The Actual Mechanics — How We Do It
When we ship a feature, we try to write about the specific technical decision that made it interesting. Not 'we added authentication' but 'here's why we ended up rolling our own TOTP instead of using a library, and the three things that almost broke us.'
We keep a running notes file. Whenever something interesting happens — a deploy that went sideways, a customer question that revealed a gap in our docs, a performance problem we spent two days debugging — we add a note. Then once a week, we look at the list and pick one to write about properly.
## Build log — Week of [date]
### What we shipped
- Feature X: took 3 days, should've been 1. Why? [reason]
- Fixed bug Y: turned out to be a race condition in the webhook handler
### What we learned
- Assumption Z was completely wrong
- Tool W is actually great for this use case
### Numbers
- MRR: €X
- New signups: Y
- Churned: Z (reason if we know it)
### What's next
- Building A (not announcing publicly yet until it's real)This format forces honesty. You have to fill in the numbers even when they're bad. You have to write down why something took longer than expected. Over time, it becomes a genuinely useful log for yourself — and the posts that come out of it have actual content.
The Audience Problem
Here's something nobody says enough: the audience you build by building in public is mostly other developers who are building in public. That's not your customer. Unless you're selling to developers — which we are, so this works out — you might be optimizing for the wrong crowd entirely.
If you're building a SaaS for restaurant owners, posting detailed Next.js architecture threads on Twitter/X is not going to get you customers. It might get you followers who are impressed by your stack. Those followers will not subscribe to your restaurant software.
We got lucky in that we're building developer tools, so the audience overlap is real. But we've still made the mistake of optimizing for developer Twitter instead of being where our actual customers are. Building in public has to be targeted, not just broadcast.
Building in public is a distribution strategy. Like any strategy, you need to ask: is this reaching people who might actually buy? If the honest answer is no, you're doing community theater, not marketing.
When to Share Code vs. When to Share Context
We've found that code-first posts tend to perform better on developer Twitter and do better long-term for SEO (since people search for specific solutions). Context-first posts — the 'here's what we're thinking about' stuff — do better for relationship building but decay faster.
A good pattern: lead with the problem in plain language, then show the code, then explain the trade-offs. Like this:
// The problem: we needed to rate-limit API routes per user
// without adding Redis to our stack (keeping things simple)
// Solution: edge-compatible in-memory map with TTL cleanup
const rateLimitMap = new Map<string, { count: number; resetAt: number }>();
export function rateLimit(
identifier: string,
limit: number,
windowMs: number
): { success: boolean; remaining: number } {
const now = Date.now();
const existing = rateLimitMap.get(identifier);
if (!existing || existing.resetAt < now) {
rateLimitMap.set(identifier, { count: 1, resetAt: now + windowMs });
return { success: true, remaining: limit - 1 };
}
if (existing.count >= limit) {
return { success: false, remaining: 0 };
}
existing.count++;
return { success: true, remaining: limit - existing.count };
}
// Usage in a route handler:
// const { success } = rateLimit(`api:${userId}`, 100, 60_000);
// if (!success) return new Response('Too many requests', { status: 429 });This is the kind of thing worth posting about — a real constraint (no Redis), a real solution, actual code. Not 'we optimized our API layer today 🚀'. The code is the content.
The Sustainability Question
Posting consistently is hard. Not because writing is hard, but because you eventually run out of things you want to share — or everything starts to feel either too small to matter or too sensitive to post.
We went through a phase where we stopped posting because nothing felt interesting enough. That was a mistake. The 'this isn't interesting' filter is calibrated wrong for most developers. What feels like a boring Tuesday debug session to you — where you spent three hours figuring out why your Prisma queries were doing N+1 — is genuinely useful to someone who hit the same issue last week.
The bar for sharing isn't 'is this interesting?' It's 'would past-me have found this useful?' That's a much lower, more honest bar.
Some of our best-received posts came from things we almost didn't write about because they felt too obvious or too small. The one about how we handle failed webhook deliveries. The one about our specific folder structure for Next.js routes. Neither felt impressive while writing them. Both got shared by people who were dealing with the exact same things.
The Honest Verdict
Building in public is worth it if you're selling to developers and you're willing to be genuinely specific and honest. It's a slow game — it takes months before you see any real compounding effect, and even then it's hard to attribute customers directly to specific posts.
It's not worth it if you're looking for a shortcut to distribution. It's not worth it if you're going to post vague inspiration content and call it transparency. And it's definitely not worth it if it's taking time away from actually building.
The best version of building in public is really just good documentation of your decisions, your mistakes, and your actual progress — shared in a way that's useful to people in a similar situation. That's it. It doesn't require a personal brand, a content calendar, or a thread format with numbered tweets.
Everything we build at peal.dev — the templates, the architecture decisions, the opinionated defaults — comes from us documenting what we actually use. When we built the auth template, we wrote about the hard parts. When we updated the Stripe integration to handle tax properly, we wrote about what broke in the previous version. That's the loop: build, hit a wall, write about the wall, repeat.
The best marketing for a developer product is proof that you actually understand the problems. Code, postmortems, and honest numbers are proof. Inspiration posts are not.
If you're starting out: write one post about the hardest technical problem you solved in the last two weeks. Not a thread, not a viral hook, just a clear explanation with working code. See how that lands. That's the version of building in public worth doing.