Building in Public

Why we build in public#

A common critique of physical AI demos is that they only show the success cases. If we only show the success cases, how can anyone trust them?

The same applies to startups. It applies to us.

It is in our DNA to build in public, by which I mean more than just shipping. Every startup ships. I mean writing and sharing the dead ends. Open sourcing as much code as possible. Inviting criticism. Thinking in the open.

Reasons why building in public leads to better product#

First, let's get to the selfish reasons. I have sat in too many conference rooms, meetups, sales pitches, keynotes where folks espouse lots of feelgood ideas (e.g. transparency) but they always (suspiciously) leave out “what is in it for them, the speaker?”

I will be straight up: I build better things when I do so in public. Building in public is more painful in the short run, more embarrassing, but when every day matters for a business, I'd rather hear and feel everything that does not work early and often. No amount of product or idea embarrassment compares to the long run pain of shutting a startup down.

Why does it tend to bring better products from me and my teams?

1. Public accountability ships. People simultaneously care more about what they are shipping when they know it will be public and they ALSO build a product callus to fight the tendency towards perfectionism that does not ship.
2. Burning our boats. Whenever we explain our thinking, open source code, we are burning our boats by giving any competitors as many tools as possible to compete with us. This only raises our internal stakes.
3. Nonsense gets called out. When we build in public, people call out nonsense. And while it is short term embarrassing, it can save us tons of time in the long run.
4. Lightning rods. When we build in public, it tends to create lightning rods for similar problems, opportunities, and partnerships.
5. Intellectual honesty. Building in public usually means more intellectual honesty and underpromising/over-delivering.

This won't fit every team. It fits us.

Reasons why building in public leads to better ecosystem#

Physical AI is still early. A lot of teams are hitting the same problems in parallel and quietly burning time on them.

We have seen it firsthand. Someone spends two weeks debugging URDF joint axes in a simulator. Someone else fights the same physics config a month later. Neither publishes the fix. Multiply that across every team working on sim-to-real transfer, data collection pipelines, or deployment tooling and you get an enormous amount of duplicated pain.

Building in public helps because:

1. It reduces duplicated work. If we share what broke and what we tried, fewer people repeat the same mistakes. Not everything needs to be a paper or a polished repo. Sometimes a blog post saying “this approach did not work and here is why” saves someone a week.
2. It shares the thinking, not just the code. Code shows what worked. It rarely shows the dead ends, the bad assumptions, or why something that looked promising failed. That is usually the more valuable part.
3. It makes the path more visible. Right now the gap between “I want to build something in physical AI” and “I know where to start” is enormous. Writing things down, including failures, does not make it cleaner or easier. Just more visible.
4. It lowers the barrier to entry. You should not need access to a top lab or a warm intro to a research team to figure out where the real pain points are.
5. It makes progress less dependent on luck. The more that is out in the open, the less it depends on who you know or what you happen to stumble into.

Physical AI should not feel like a black box or something you need permission to work on.

But what about competitors?#

Hemingway wrote: “There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”

If someone takes what we have and does it better, then we did not earn it. That is on us.