What If?

Recently, I’ve had to accept a difficult reality: I’ve spent years trapped in a loop of optimizing for certainty rather than action.

For someone who spends most of his time building things, I’ve shared remarkably few of them. I’ve always given myself a reason. The UI wasn’t finished. The architecture wasn’t quite right. There was always one more thing to improve before I could put it out into the world.

Looking back, those reasons were rarely the real problem.

I always built with an audience in mind. What will people think? What if this looks amateur? What if the project isn’t good enough? Every choice felt important. Every project felt permanent. Instead of sharing things and learning from them, I kept searching for certainty.

Underneath it all was fear. As long as a project remained unfinished, it could still be perfect.

Eventually, the cycle became exhausting. What began as excitement slowly turned into obligation.

The irony is that I thought I was protecting my work.

By keeping projects private, I could avoid criticism, failure, and looking foolish. But I was also avoiding the very thing that helps ideas improve.

Software gets better when people use it. Writing gets better when people read it. Ideas get better when they’re challenged.

Instead, I had created a closed system. The only feedback came from me. The result wasn’t better work. It was stagnation.

So this is my experiment.

To share things before they feel ready. To treat projects as opportunities to learn rather than reflections of my worth. To stop optimizing for certainty and start optimizing for feedback.

I’m sure I’ll publish things that are incomplete. Some ideas will be wrong. Some projects won’t go anywhere.

That’s fine.

For years, the question that stopped me was simple:

What if?

What if the project fails? What if it’s not good enough? What if nobody cares?

I’m starting to think there’s a more interesting question:

What if I publish it anyway?