41 apps built. 10+ dev teams enabled.

Somewhere in your company an internal champion put AI on the team’s desks — and it worked. Within a month the whole team is building everything under the sun, faster than review, security, and architecture can keep up. The enthusiasm is the asset. Unmanaged, it’s also the exposure: unreviewed generated code heading for production, sensitive context leaving the building, architecture decisions delegated to a model nobody’s verifying.

Your team doesn’t need to be told what’s possible — they’re living it. What they need is guidance on where AI belongs in the system, safety in how it gets used, and oversight that proves it’s working. That’s this practice. We’ve run it for 10+ software and product companies, since before agents existed.

The engagement is working when we’re no longer the ones presenting. At one current client, a few months in, their own senior engineer ran the AI dev-practices session for the whole team — our written guidance, contextualized to their systems, in his voice, on his slides. That’s the durability you’re buying: adoption that doesn’t depend on us being in the room.

What that team now teaches itself:

How does a whole company get there — not just the engineers? The ladder is the same every time. This is it verbatim, as we wrote it to a client CTO mid-engagement:

And it happens one person at a time, without rushing — rushing ruins it. Every function has its own curve: HR and accounting move fast once past the learning curve, sales is slow then fast, operations is always slow, then fast. No penalties. Time.

This isn’t advice from the sidelines. 41 apps built with AI — 11 commercial, all under NDA, several in production; 30+ personal, many born at our live workshop’s open-build floor. Thirty days each, a working build every week, revisions in writing. Every practice on this page runs in our own production systems first.

Need the app built rather than the team enabled? Same practice, same cadence — and honest platform advice up front: most “apps” ship best as mobile web apps, PWAs, or Chrome extensions. We build native when the product demands it, and say so when it doesn’t.

From Peter’s workbook: what the economics of code look like once agents generate it — and how carefully code gets read before it merges, from throwaway experiments to “people could die.”

None of this runs on vibes. Every build and every enablement ships the same operating system — rules we run on our own production systems daily, written the hard way, and installed into every client team we touch.

Straight talk: the enablement practice largely predates agents — and predates our habit of banking dollar figures. We won’t retrofit revenue claims onto engagements that didn’t track them. What was measured rigorously was velocity against a captured baseline — and on the build side, shipped software on a written cadence.