Why we build our own products before teaching anyone

There is a simple test for anyone offering to teach your engineers how to work with AI agents: ask what they shipped with them last month. Not a demo. Not a prototype. Something with users and a bug tracker.

Most of the people selling this cannot answer. That is not a character flaw. It is a structural one. If your business is advice, you have no reason to carry the cost of being wrong in production. So the advice drifts toward what sounds good in a workshop and away from what survives a Tuesday afternoon incident.

We decided to pay that cost ourselves. wildcard* builds Even, an AI operator for movement studios (yoga, pilates, martial arts, dance, fitness), with agent teams, every day. Agents plan, implement, review and test. People set direction and approve. Everything we put in a briefing has run on that codebase first.

This changes what we teach in three ways.

First, we teach the boring parts. Agent teams do not fail on the clever bits. They fail on conventions nobody wrote down, tests that do not exist, and review queues that quietly double. We know because we hit all three. The fixes are unglamorous and they are the whole game.

Second, we have numbers. When a CTO asks what happens to review load, we do not estimate. We show what happened on Even, week by week, and what we changed when it went the wrong way.

Third, we lose the incentive to oversell. If a practice does not hold up on our own product, it is gone from the material. There is no slide to protect.

The order matters: build, then teach. Reverse it and you get a consultancy with opinions. Keep it and you get a product studio that has to be right, because it is running the same thing it recommends.

That is also why Even is on the Work page with its build process shown. Judge the method by the product. If the product does not convince you, the briefing should not either.