Founders Note #9

Building in Public

Building in public has always felt natural to me. I like the transparency, the feedback, and the connection that comes from letting people see the process, not just the final product.

But it took me a long time to learn that not all feedback is direction.

When I built my first app, IWantToPractice, I said yes to every suggestion that came my way.

“Can it track this?”

“Can it do that?”

“Can it remind me of students' birthdays?”

People seem to want an all-in-one, but often they fall short and become overly complex and not very good at anything. Even I wasn’t 100% sure how to use certain parts of it anymore.

That’s when I learned one of the hardest lessons in building products:

Feature creep kills clarity.

Simplicity isn’t about doing less; it’s about doing what matters most. There’s a fine line between being minimal and being ineffective.

I think about this a lot when I look at companies like Google and Apple. Google experiments in public, releasing things early, collecting feedback, and improving through iteration. Apple, on the other hand, stays behind the curtain until the moment it’s perfect.

Both approaches work. But personally, I resonate more with the Google approach. I’d rather build something people can touch and test, even if it’s not perfect yet. Because that’s how you learn what really matters to the people using it.

When you build in public, you’re not just creating a product, you’re building trust. You’re letting users see how decisions are made, how ideas evolve, and how their feedback shapes the outcome. It makes them part of the process, not just consumers of it.

That’s the beauty of early-stage building. People don’t just use what you create; they help create it with you.

And that shared sense of ownership? That’s what keeps them around long after the launch.