Back to blog
Editorial illustration of a founder's workspace behind a large glass wall, most of it transparent and open to show a desk with notebooks and a glowing laptop while one section is frosted to hide a private corner, representing building in public with deliberate limits on transparency
Our Mission

Building in Public: What I Share, What I Don't, and Why Transparency Has Limits

Jun 22, 2026 7 min read Avinash Tyagi
building in public build in public startup transparency building in public startup founder journey indie hackers transparency saas startup startup founder building in public 2026

Back with another one in the founder series. This one is uncomfortable to write, because it is about the gap between the version of building in public that gets celebrated online and the version I actually practice.

If you spend time around indie founders, you know the building in public playbook. Post your revenue. Post your churn. Celebrate every Product Hunt launch. Share the wins and the losses and let the internet ride along. I bought into that early. Then I started actually running a company and learned that radical transparency and good judgment are not the same thing. Call this my honest field guide to startup transparency, from someone still in the middle of it.

What building in public was supposed to be

The pitch is good. You share the journey of building a startup out loud, in real time, instead of hiding behind a polished launch. Transparency builds trust, trust builds an audience, and that audience becomes your first customers and your honest feedback loop. Plenty of SaaS companies and open startups have grown this way, and the public accountability creates a culture where you actually ship.

I still believe most of that. When I started writing about Levelop, the engineers who showed up were not there for a sales pitch. They were there because I was working through the same problems they were stuck on, in the open, and getting some of them wrong. People do not connect with the highlight reel. They connect with the person fumbling toward something real.

The gap nobody talks about

Here is what tripped me up. The loudest advice treats sharing as a single dial you turn up. More transparency, more trust, more growth. Turn it to eleven and win.

But sharing is not one dial. It is a dozen separate decisions, and they do not all point the same way. Sharing how I think about a feature is almost free and almost always helpful. Sharing a user's data is never okay. Sharing a revenue number feels brave but can quietly box me into decisions I would not otherwise make. Treating all of those as the same act, all good because transparency is good, is how thoughtful founders end up doing dumb things on purpose. Once I separated the decisions, the question stopped being "should I build in public" and became "what exactly am I about to share, who does it affect, and what does it lock me into."

What I share, and why it is worth it

I share the thinking. The reasoning behind a product decision is the most valuable thing I can give away, and it costs me almost nothing. Ideas are cheap, execution is the moat, so I give the ideas away freely.

Some of that thinking turns into posts of its own, like why we teach twelve coding interview patterns instead of grinding thousands of problems, or what building an AI mentor taught me about how engineers actually learn.

I share the mistakes, but only after I understand them. A mistake you have processed is a lesson. A mistake you are still inside is just a wound you are showing strangers.

I share the craft. How I write, how I research, how the content pipeline behind this blog runs. Process is a gift you can give without giving anything away.

I share direction. As an early stage founder, the direction matters far more than the dates. Direction signals conviction. Specific promises signal a debt you may not be able to pay.

What I do not share, and why the limits matter

I do not share other people's data. This is not a judgment call, it is a line. The engineers who use Levelop trust me with how they learn and where they struggle. None of that is mine to turn into a content moment. "Real stories, real numbers" sounds great in a marketing meeting and becomes a privacy violation the second you attach it to actual humans without their explicit consent. When I do write about user outcomes, it will be with people who asked to be part of it, in their words.

I am careful with revenue numbers. This is where I part ways with a lot of the build in public orthodoxy. Once a number is public, it starts steering you. You optimize for what looks good in the next monthly update instead of what builds a durable company. Posting revenue can quietly trade long term judgment for short term applause, and I would rather keep my judgment.

I do not narrate half-formed strategy in real time. Public strategy is most valuable to a competitor while it is still forming, and narrating a decision while you are still making it pressures you to commit before you have thought it through. I will tell you what I decided and why, after I have decided.

I protect the team. My team members' struggles, a partner conversation, a deal that did not happen, those belong to other people too. Building in public is not a license to narrate other people's lives without asking.

A framework I actually use

I run anything I am about to post through four quick questions, in order. First, whose information is this? If the answer is someone other than me, I stop. Second, would I be fine with this being public even if I turn out to be wrong? Thinking and process clear this bar; predictions usually do not. Third, does sharing this lock me into a decision I might need to reverse? Public commitments pull future choices toward consistency instead of correctness. Fourth, am I sharing this because it is useful, or because it performs well? The dopamine of a transparency post is not the same as it being honest or helpful.

Most things I want to post clear all four. The ones that fail usually fail on the first or third question, and those are exactly the ones that feel the most brave.

Decision filter for building in public: four questions (whose information, fine if wrong, does it lock me in, useful or just performs well) sorting what a founder shares freely (thinking, mistakes, craft, direction) from what to hold back (other people's data, revenue, half-formed strategy, anything not yours to tell)
The filter, not the dial: each thing you could share runs through four questions, sorting what to share freely from what to hold back.

Why I still build in public anyway

After all the caveats, I would not run Levelop any other way. Building in public, done with judgment, has given me a tighter feedback loop and a record of my own thinking that has made me a better founder just by forcing me to articulate it. It creates a culture of accountability that only gets more valuable as the business grows. The mistake is treating transparency as an on switch. The skill is treating it as a series of deliberate choices, where the default is openness about your own thinking and the hard line is respect for everything that is not yours to give.

If you are starting out, do not ask how transparent you can be. Ask what each specific thing will cost, and who it belongs to. The founders who last are not the most exposed. They share generously and draw their lines clearly, and never confuse the two.

Frequently asked questions

What does building in public actually mean?

Building in public means sharing the process of building a startup or product openly, in real time, instead of working in secret until a polished launch. It usually includes your thinking, your progress, your mistakes, and sometimes your metrics. In practice it is less a single behavior and more a set of choices about what to share and what to hold back.

Should startups share their revenue when building in public?

It is genuinely optional. Public revenue can build credibility fast, and for some founders that has worked well. The hidden cost is that a public number starts steering your decisions toward what looks good in the next update rather than what is best long term. If sharing revenue would tempt you to optimize for applause over judgment, it is reasonable to keep it private.

Is there a downside to building in public?

Yes. The main risks are oversharing other people's data, narrating strategy before you have thought it through, and creating public commitments that box in future decisions. There is also a subtler risk of optimizing your work for what performs well online instead of what actually moves the business.

How do you decide what is safe to share?

A simple test helps: would this still be fine to have published even if you turn out to be wrong about it? Your thinking, your process, and your own mistakes almost always pass. Predictions, promises, and other people's information usually do not.

Does building in public still work in 2026?

It still works, but the bar is higher because so many founders are doing it. Generic progress updates and revenue screenshots blend into noise. What stands out now is genuine reasoning and a real point of view, the things that are hard to fake. Transparency about your thinking is more durable than transparency about your numbers.

Where to go next

These founder reflections sit alongside the work itself. Read why we teach twelve patterns instead of 2500 problems, what building an AI mentor taught me, and the story of how I failed four FAANG interviews and built a platform. For more, visit the Levelop blog or the Levelop home page.

Keep reading

Our Mission

Why Levelop Teaches 12 Coding Interview Patterns Instead of 2500 Problems

The case for less. Why a focused set of 12 coding interview patterns, understood deeply, beats grinding 2500 LeetCode problems, backed by the cognitive science of how experts actually think.

Read article
Our Mission

FAANG Interview Prep: I Failed 4 Times, Then Built Levelop

I failed four FAANG interviews doing everything I was told. Here is what actually went wrong, the dozen patterns that fixed it, and why I built Levelop around recognition, not memorization.

Read article