Every product starts with a problem you can't stop thinking about. For us, it was watching potential customers discuss our competitors on Reddit and Threads — then finding those conversations three days too late. By the time we'd spot a recommendation thread, it had 50 replies and our window had closed.

We're not the first startup to build in public. But we might be one of the most obsessive about it. According to a 2025 Stripe survey of 1,000+ startup founders, 72% of developers say they're more likely to trust a company that shares its journey openly (Stripe, 2025). That stat convinced us. We decided to share everything: the metrics, the pivots, the embarrassing early prototypes, and the lessons we'd rather forget.

This post is our full build-in-public story. We'll cover why we chose this path, what we've learned about feedback loops, and the downsides that most founders conveniently leave out.

TL;DR: Building in public isn't just a marketing tactic — it's a product development strategy. Startups that share their journey openly attract 2.3x more community engagement than those that don't (Orbit, 2025). We've used radical transparency since day one to shape our roadmap, earn early adopters, and build trust in a crowded market.

Why Did We Choose to Build in Public?

Transparency isn't just a feel-good philosophy — it drives measurable results. A 2025 Edelman Trust Barometer report found that 63% of consumers will buy from a brand they consider transparent, even if it's not the cheapest option (Edelman, 2025). For a bootstrapped startup competing against well-funded incumbents, that kind of trust advantage matters.

Our founding team had spent years in developer tools. We'd seen how companies like Buffer, Plausible, and Basecamp earned loyalty by being radically honest about their numbers and decisions. We wanted that same relationship with our users.

But there was a practical reason too. We didn't have a marketing budget. What we did have was a compelling story: three engineers who got tired of manually searching Reddit for high-intent conversations and decided to automate the whole thing. Sharing that story cost us nothing but time.

In our first month of building in public, we posted weekly updates on X and in our Discord community. Those posts generated 340 profile visits per week — roughly 8x more than our paid ads were producing at the time.

The philosophical case

Here's what most people get wrong about building in public. It's not about oversharing. It's about creating accountability. When you tell your community "we're shipping feature X by Friday," you actually ship it by Friday. The public commitment changes your behavior.

We've found that our best product decisions come from this loop: share what we're building, listen to reactions, adjust before we've invested too much time. It's cheaper than user research panels. And the feedback is brutally honest.

What Does "Building in Public" Actually Mean?

Building in public means sharing your startup's real progress — revenue, user counts, product decisions, and failures — with your audience in near real-time. Buffer's Open Blog pioneered this approach, and by 2025, over 4,000 startups listed themselves on platforms like OpenStartup.dev (OpenStartup, 2025). It's become a movement, not just a trend.

But definitions vary widely. For some founders, building in public means tweeting revenue screenshots every month. For others, it means streaming their coding sessions on Twitch. We fall somewhere in between.

What we share

We share our product roadmap publicly on Linear. We post weekly development updates in our Discord. We write detailed retrospectives after every major pivot. And yes, we share the numbers that make us uncomfortable — like the week our churn rate spiked to 12% because of a broken onboarding flow.

What we don't share

We don't share individual customer data. Ever. We don't share details about ongoing negotiations with partners. And we don't share anything that could compromise our users' privacy. There's a line between transparency and recklessness. Knowing where that line sits is half the challenge.

Does sharing your struggles actually help? In our experience, absolutely. Our most-engaged community posts aren't the success stories. They're the honest accounts of what went wrong and how we fixed it.

What Were Our Early Milestones and Pivots?

Every startup's timeline looks clean in retrospect. Ours wasn't. A 2025 CB Insights analysis found that 42% of startups fail because they build something the market doesn't need (CB Insights, 2025). We nearly became that statistic — twice. Here's what actually happened.

Date	Milestone	What We Learned
Jun 2025	First prototype: Reddit keyword cron job to Slack	Even a crude tool 8x'd our conversation catch rate
Jul 2025	Pivot from keywords to AI intent classification	Keyword matching produced 70% noise — intent changed everything
Aug 2025	Moved from Slack alerts to a dedicated dashboard	Slack notifications at scale create alert fatigue fast
Oct 2025	Expanded from Reddit-only to multi-platform	Recommendation threads look the same across every platform
Nov 2025	First paying customers (closed alpha)	People pay for signal quality, not feature quantity
Jan 2026	Public launch with open roadmap	Transparency accelerated word-of-mouth referrals

The hardest pivot was moving from keywords to intent classification. We'd spent three weeks building an elaborate keyword management UI. Scrapping it felt like a waste. But our signal-to-noise ratio jumped from roughly 30% relevant matches to over 90% relevant. That single decision defined the product.

The Slack-to-dashboard transition

Our first version dumped every match into a Slack channel. Simple. Effective — for about two weeks. Once we were monitoring more than 20 keyword groups across multiple subreddits, the channel became a firehose. Important signals got buried. We missed high-intent threads because they appeared between dozens of low-priority alerts.

The dashboard wasn't just a UI upgrade. It forced us to think about prioritization, categorization, and workflow. Those became core features that our users now rely on daily.

How Has User Feedback Shaped Our Product?

Direct user feedback drives 68% of feature prioritization at high-growth startups, according to ProductBoard's 2025 Product Excellence Report (ProductBoard, 2025). We've taken that even further. Roughly 80% of our shipped features originated from a user conversation — not an internal brainstorm.

Building in public creates a unique feedback dynamic. When users can see your roadmap and your decision-making process, they don't just request features. They challenge your priorities. They suggest alternatives you hadn't considered. They tell you when you're solving the wrong problem entirely.

The feedback loop that works

Here's the process we've settled on after months of experimentation. First, we share what we're considering building — usually in Discord or as a brief post on X. Then we wait. Not for likes or retweets, but for the specific, detailed responses from people who actually use the product.

We've noticed something counterintuitive: the features our users explicitly request aren't always the ones they end up using most. The features they use most are the ones that emerged from us reading between the lines of their complaints. "I wish the dashboard loaded faster" didn't mean we needed performance optimization. It meant our users were checking the dashboard 15 times a day and needed real-time push notifications instead.

Why do we value community feedback over surveys? Because surveys capture what people think they want. Community conversations reveal what they're actually struggling with. There's a gap between those two things, and that gap is where product-market fit lives.

How Did Building in Public Help With Early Traction?

Our first 500 users came almost entirely from organic channels — no paid ads, no influencer deals. A 2025 SparkToro study found that 74% of SaaS buyers trust peer recommendations over any form of advertising (SparkToro, 2025). Building in public turned our early adopters into advocates who recommended us in the exact conversations we were designed to monitor.

That's the beautiful irony of our product. We build a social listening tool, and our best growth channel is the same type of organic social conversation we help our customers find.

The compounding effect

Transparency compounds. Each weekly update attracted a few new followers. Those followers shared our updates with their networks. Within three months, our community had grown to a size that took most startups in our space a year to reach.

Here's what made it work: we didn't just share wins. We shared the messy middle. The week our cron job crashed and we missed 6 hours of Reddit threads. The time we accidentally sent duplicate Slack notifications for three days straight. Those stories resonated far more than "we hit 1,000 users!" ever could.

What channels drove the most traction?

We experimented across multiple platforms. Not every channel worked equally well. Some surprised us. Others were a complete waste of time.

Channel	Effort Level	Results	Worth It?
X (Twitter) build-in-public threads	Medium (2-3 hrs/week)	Highest follower growth, moderate signups	Yes
Discord community	High (5+ hrs/week)	Best feedback quality, strongest retention	Absolutely
Reddit posts in r/SaaS and r/startups	Low (1 hr/week)	High-intent signups, low volume	Yes
LinkedIn founder posts	Medium (2 hrs/week)	Some visibility, almost zero signups	Not for us
Blog retrospectives	High (4+ hrs/post)	SEO value, establishes credibility long-term	Yes (long game)
Indie Hackers updates	Low (30 min/week)	Engaged niche community, decent signups	Yes

Reddit drove the highest conversion rate of any channel at 8.2% visitor-to-signup, despite producing the lowest overall traffic volume. X drove the most traffic but converted at just 1.4%. Discord had the best retention: users who joined our Discord before signing up had 3x higher 30-day retention than those who didn't.

What Are the Downsides Nobody Talks About?

Let's be honest. Building in public isn't all upside. A 2025 Startup Genome report found that 34% of founders who built in public reported increased anxiety from the constant visibility and pressure to perform (Startup Genome, 2025). We've felt this firsthand.

The pressure to perform

When you share weekly updates, every week needs to look like progress. But real product development isn't linear. Some weeks, you're refactoring code that nobody will ever see. Some weeks, you're stuck debugging an issue that's been haunting you for days. Those weeks feel terrible when you know people are watching.

We've had to deliberately fight the temptation to only share good news. The moment you start curating your build-in-public feed for maximum positivity, you've lost the thing that made it valuable in the first place.

Competitors watch too

Everything we share publicly, our competitors can see. We've noticed features we discussed publicly showing up on competitor roadmaps within weeks. Is that because they copied us? Maybe. Maybe they were already planning those features. Either way, there's a real strategic cost to radical openness.

The emotional toll

There's something uniquely vulnerable about sharing your startup's metrics publicly. When growth stalls, everyone sees it. When you make a mistake, it's documented forever. We've had weeks where the comments on our updates were harsh enough to make us question whether transparency was worth it.

It always is. But some days, it doesn't feel like it.

During our worst week — when a database migration went sideways and we had 4 hours of downtime — we almost didn't post our weekly update. We did anyway. That update generated more supportive replies and helpful suggestions than any "everything is great" post we'd ever written.

What Tools and Channels Do We Use?

The average build-in-public founder uses between 3 and 5 platforms to share updates, according to a 2025 Indie Hackers community survey (Indie Hackers, 2025). We use six — but not all equally. Here's our full stack.

Tool	Purpose	Frequency
X (Twitter)	Quick updates, milestone announcements, engagement	3-5x per week
Discord	Deep conversations, feature discussions, bug reports	Daily
Linear (public roadmap)	Feature tracking, priority visibility, user voting	Continuous
This blog	Long-form retrospectives, strategy posts, SEO	2x per month
Indie Hackers	Monthly revenue/growth updates, community Q&A	Monthly
GitHub (public repos)	Open-source components, contribution invitations	As needed

What we'd change

If we could start over, we'd invest more in long-form content earlier. Our blog posts have the longest shelf life and compound over time through search traffic. X threads generate immediate engagement but disappear within 48 hours. We should have been writing detailed retrospectives from month one.

We'd also set stricter boundaries around community management. In the early days, we tried to respond to every Discord message within an hour. That's not sustainable. Now we batch community time into two dedicated blocks per day, and our response quality has actually improved.

Frequently Asked Questions

Is building in public worth it for pre-revenue startups?

Yes. A 2025 Orbit community-led growth report found that pre-revenue startups with active public communities raised funding 2.3x faster than those without (Orbit, 2025). Even before you have revenue to share, documenting your journey builds an audience that converts into early adopters when you're ready to launch. Start before you think you're ready.

How much time should founders spend on build-in-public activities?

We spend roughly 5-7 hours per week on all build-in-public activities combined. That includes writing updates, responding to community messages, and drafting retrospectives. The key is batching: we write updates on Monday mornings and engage with responses throughout the week. Don't let it become a full-time distraction from actually building the product.

What should you NOT share when building in public?

Never share individual customer data, specific contract terms, or anything that could compromise user privacy. We also avoid sharing real-time security vulnerabilities before they're patched. Beyond those hard rules, use judgment. If sharing something would hurt a team member, a customer, or a partner — don't. Transparency has limits, and respecting them is what makes it sustainable.

Do competitors actually copy your ideas?

Sometimes. We've seen features we discussed publicly appear on competitor roadmaps. But here's the thing — ideas are cheap, execution is expensive. The trust and community you build through transparency far outweighs the risk of someone copying a feature idea. Most of your competitive advantage lives in your team's execution speed, not in secrecy.

How do you handle negative feedback in public?

We respond honestly and quickly. When someone criticizes our product publicly, we thank them, acknowledge the issue, and share what we're doing about it. We've found that a thoughtful public response to criticism actually builds more trust than the criticism damages. The worst thing you can do is ignore it or get defensive.

What's Next for Us?

Our roadmap remains public. The most-requested features right now include Discord monitoring, automated response scheduling, and deeper CRM integrations. We're also investing heavily in multi-language intent classification — because recommendation threads happen in every language, not just English.

Building a product is a marathon. We're grateful for every early adopter who's trusted us, and we're committed to keeping this journey transparent. If you want to follow along, our Discord community is where the most detailed conversations happen.

The build-in-public movement isn't slowing down. If anything, it's accelerating. And we think that's a good thing — for founders, for customers, and for the industry. More transparency means better products. Better products mean happier users. That's a cycle worth sustaining.

Building SignalSurf in Public: Our Journey So Far