There's this pressure in the indie hacker community to share everything. Your launches, your failures, your daily struggles—all of it. The logic makes sense: vulnerability builds connection, transparency builds trust, and documenting your journey helps others. But after building in public for a while, I've learned that "share everything" is actually terrible advice.

The real skill isn't radical transparency. It's knowing where to draw the line.

The Allure of Total Transparency

When I started Jottings, I was inspired by founders who documented everything. Their honest failures felt authentic. Their revenue breakdowns seemed generous. Their public struggles humanized the entrepreneurial journey. I thought: if they can do it, so can I.

So I did. I shared launch updates, metrics, design decisions, technical choices—all of it. And honestly? Most of it was fine. But around the six-month mark, I hit a wall.

Someone had reached out about investing. Another person asked for advice on their competing product. A potential customer saw metrics that made them hesitant (even though they didn't fully understand them). I realized I'd created a transparency problem, not a transparency solution.

The issue was that I'd conflated "being honest about my journey" with "sharing every piece of information I own." Those are very different things.

What You Can Freely Share

Product decisions and features: How you built something, why you chose certain technologies, design principles—this stuff helps people. There's almost no downside to explaining your architectural choices, your UI decisions, or how you're thinking about user experience.

Learning and failures: I talk openly about failed experiments, features that didn't work, growth strategies that fizzled. This is genuinely useful. People don't need your wins; they need to understand where you've gone wrong and what you learned.

Philosophy and values: Your approach to building, your thoughts on community, your perspective on indie hacking—these create connection and attract like-minded people. This is the stuff that builds real community.

High-level growth patterns: "We grew 30% month-over-month" or "We hit 1,000 users" can be shared. These milestones are public celebrations of progress without exposing vulnerability to competitors or bad actors.

Process and workflow: How you manage your time, your tools, your writing process, your debugging approach—this is endlessly useful and has zero downside.

What Deserves Careful Consideration

Exact revenue and unit economics: Here's the thing: sharing that you make $5K MRR feels vulnerable and authentic. But it also tells competitors your margins, gives bad actors information for targeting, and can create unnecessary tension with co-founders or potential hires who do the math differently.

Instead of exact numbers, share your thinking: "We're focusing on sustainable growth rather than maximizing MRR," or "We prioritize unit economics over raw revenue growth." People understand the intent without the specifics.

Specific customer struggles: If a customer is struggling with your product, that's real feedback. But sharing the specific customer's issue (even anonymized) can create friction. Instead, abstract the lesson: "We learned that users often misunderstand feature X, so we redesigned the onboarding."

Personal mental health and burnout: I've seen founders share about anxiety, depression, or burnout, and it resonates deeply. But there's a line between "I struggled with founder burnout and here's what helped" and oversharing details that can become a liability later.

Share the transformation, not the crisis details.

Partnership and business negotiations: Even if you trust your audience, don't discuss active negotiations, partnership terms, or strategic decisions that haven't been finalized. Someone in your audience might be connected to the people you're negotiating with. You also lose leverage once information is public.

Disagreements with collaborators: You might have different opinions from your co-founder, advisor, or team member. Airing that publicly is the fastest way to damage relationships and credibility. Handle it privately, then share the solution if it's relevant.

What Must Stay Private

Employee and team information: Your team members didn't sign up for public documentation. Period. Don't share their struggles, salaries, disagreements, or personal details without explicit permission. If you're a solo founder, this doesn't apply, but the moment you're not alone, their privacy isn't yours to give away.

Specific investor terms: Don't publicly discuss who invested, how much they invested, or the terms. It creates unnecessary complications and exposes information that wasn't meant to be public.

Customer data and usage patterns: Even aggregated, be cautious. "Our top customers use feature X" might reveal competitive intelligence you should keep quiet about.

Detailed financial struggles: There's a difference between "we're managing cash carefully" and a day-by-day breakdown of runway anxiety. The former is honest; the latter is oversharing. Detailed financial distress can scare customers away, harm investor confidence, and give competitors insight.

Unfiltered personal life: Your politics, your family drama, your medical history, your relationship struggles—these don't need to be public. You can be authentic without being completely transparent. Authenticity means being genuine, not being unfiltered.

Immature thoughts you haven't processed: If you're angry at a competitor, frustrated with a customer segment, or having doubts about your product, take time to process before sharing. Your hot take from this morning might not reflect your actual values. Give yourself permission to think through things privately first.

Finding Your Comfort Zone

This isn't about being deceptive. It's about being thoughtful.

I've learned that my comfort zone is:

• Sharing technical decisions and learning openly
• Being honest about the building process without oversharing metrics
• Discussing the founder's journey without exposing the full picture
• Talking about what works and what doesn't without revealing exact numbers
• Being personal about my philosophy without being exposed about my struggles

It's not as radical as some builders practice. But it's more honest than saying nothing.

Your comfort zone will be different. You might be comfortable sharing revenue publicly (and you might reach a point where it's no longer safe to do so). You might want to keep most things private and only share wins. Both are valid.

The key is intention over reflexivity. Ask yourself before hitting publish: "Am I sharing this to help people, or am I sharing this for external validation?" If it's the latter and it exposes something private, don't share it.

The Practice

Building in public is still worthwhile. Your journey helps people. Your honesty creates connection. But connection doesn't require complete exposure. It requires authenticity—being genuinely yourself—which is different.

You don't owe anyone your full story. You owe yourself thoughtfulness about what parts to share and why.

Start sharing more than feels comfortable. Then gradually refine your boundaries as you see the real costs and benefits. This is the learning curve of building publicly, and it's okay to adjust as you go.

Your journey is valuable. Your boundaries are too.

If you're building something and thinking about how to document your journey publicly, consider starting with your own "what to share" framework. What feels right for your values? Build from there. And if you're building a space where people share—like Jottings—maybe that framework is exactly what your community needs.