Building in Public Without Giving Away the Work

I’m building in public — carefully. The work involves AI systems, knowledge graph architecture, and the kind of governance logic that takes time to get right. Sharing the journey is part of how I’m developing: testing ideas, getting better at building with AI, figuring out what direction is worth pursuing. But some of what I’m building is the kind of thing that only has value if it remains proprietary. So I’ve had to think hard about what “building in public” actually means when the implementation is the competitive advantage.

There are two wrong ways to build something you can’t fully show yet.

The first is silence. Work in private, reveal it whole. The logic seems sound — don’t give away what you’re building before you’ve built it. What actually happens is you disappear. The audience you’d need to trust the thing when it launches never learns to trust the thinking behind it. You surface with a finished product and expect people to care about it cold.

The second is full transparency. “Build in public” has become its own genre, and if your competitive advantage isn’t in your implementation, it’s a reasonable strategy. But if what makes what you’re building valuable is how you built it — the specific architecture, the combination logic, the decisions that took a year to get right — sharing everything is handing over the work.

Neither is a visibility problem. The real question isn’t how much to share. It’s what.

There are three tiers, and the line between them is the whole thing.

The first is the thesis — the problem you’re solving and why the current approaches don’t solve it. This is always shareable. If your argument is that existing solutions are built on the wrong mental model, publish that argument. If someone reads it and gets there faster, fine. The thesis isn’t the work. It’s the argument for why the work needed to exist, and no one can take that from you by agreeing with it.

The second is principles — the architectural reasoning that flows from the thesis. Not the implementation, but the governing logic: why this approach and not that one, what constraints shaped the decisions, what tradeoffs you accepted and why. The test is whether someone could understand why you made a decision without being able to replicate it. If yes, it’s discussable. This is also the most durable thing you can publish. Architectural decisions change across versions. The governing principle usually doesn’t. Building in public at the principles level means you’re describing something that remains true as the implementation evolves — not documenting a snapshot that’s already becoming obsolete.

The third is implementation — the specific schema, the combination logic, the entity resolution approach. The parts that took the most time are the parts most worth protecting. The test is direct: if sharing it would let someone skip the hard part you did, don’t. If it helps them understand why the hard part was necessary, share it.

Most people who stay silent are protecting the wrong tier. They guard the thesis — the argument — because it feels like the idea. But the idea is the least defensible thing you have. Someone else will have it. What they won’t have is the time you spent figuring out why it’s harder than it looks, and the specific decisions that shaped what came out the other side. The silence meant to protect the work just keeps the argument hidden — and leaves the work without an audience when it arrives.

Share the argument. Explain the logic. Protect the implementation.

That’s the whole move.