Revision 1. /how-i-built-it/two-people. First person, plain, no em dashes.
This piece owns the Sunday call and the CRM failure. The story page compresses both and links here.
Six brackets. Two of them block publication and they are listed at the foot.
Alan and I had a standing call on Sunday nights at seven. We had been doing it for years. One week I asked Brad Brisco to join.
I did not want to describe the idea, so I built it instead. A quick site, made in an afternoon, showing a hundred potential authors as a network with the two of them at the origin. You could click any node and get the person, a rough estimate of what a platform might earn them, and what the whole network came to. I shared my screen and let them click on it.
What I said on that call is close to what the business is now. I offered them ten percent each.
What I did not know, and I want to be accurate about this, is that it would lead to organizations. I knew it had to lead somewhere. That took another year to see.
Why I started with people I knew
By then I had spent close to three years using this technology in front of people, all of it free, all of it alongside a full time job. A close friend first, then a team at a large manufacturer, then a philanthropy group, then a nonprofit here in Kansas City, then movement leaders.
The obvious move with that experience is to pick a market and build for it. I did not, for a reason I would defend and one I would not.
The one I would defend is that I do not think you learn what somebody needs by studying the category they belong to. I ran an intentional community for eleven years before any of this. You learn what a person needs by being in the room with them, in their language, for a long time.
The one I would not defend is that I did not think about money at all until I decided to start a company. That is not discipline. It is just how I am built, and it happened to work out, because a market built on trust was not open yet and would not be for another two years.
So I built for two situations I actually knew.
The first. A body of work in pieces.
Search for the questions Alan Hirsch has spent his life answering and you will mostly find other people restating him. Some of them get it right. Some do not, and the ones who do not are frequently the easier read, so they travel further.
Twenty thousand notes. More than a decade of them. Books, talks, half finished thoughts, things written on planes. The work was all there. It was not anywhere you could get to.
The problem was never storage. Anyone can put twenty thousand notes in a database.
The problem is that the moment you make an archive answerable, you have built something that speaks in a person's name. If it says something he would not say, you have not helped him. You have added one more confident wrong voice to the pile that was the original problem.
So the build had two requirements that pull against each other. It had to actually answer. And it had to only ever say things he had said.
[THE BUILD. Six to ten sentences, chronological, plain. The retrieval approach and why grounding in his own notes rather than a general model wearing a persona. How citation works and what it refuses to do without sources. What had to be structured before any of it worked. Name the real choices, including ones you would make differently now. Specific enough that a builder could follow it.]
[THE PROOF. One checkable thing. A link someone can open, a number with a date on it, a capture. If the honest proof is small, use the small one. "It works well" is not proof.]
The second. An organization AI had already walked into.
The second is a nonprofit here in Kansas City where I have known people for years. They are unnamed until the work is finished and they have agreed to be named, because a progress report is not a case study.
Their problem was not an archive. It was that AI was already inside the organization and nobody had decided anything about it. [SPECIFIC. What was actually happening. Staff on personal accounts, information going into tools nobody had approved, whatever the real version was. One or two sentences, said plainly, without making anybody look foolish, because nobody did anything unreasonable.]
Nothing had gone wrong. That is the part people miss. Nothing had gone wrong yet, and the absence of a bad day was being read as evidence there was nothing to decide.
I could have written them a policy in a week. It would have sat in a folder.
What we are doing instead is a hundred hours of in person training, alongside the build. [WHAT A SESSION ACTUALLY LOOKS LIKE. Two or three sentences. Who is in the room, what happens, what is different for a staff member between hour one and hour forty.]
A hundred hours is a lot to ask of a nonprofit and I am not going to dress that up. It is the most expensive thing about how I work and I have not found a way around it that I believe in.
Why the hundred hours exists
This is the part I would skip if I were trying to make the work sound easier, so here it is.
For three years I showed this technology to everyone I knew, for free, as well as I know how to show anything. People were astonished and people did not adopt. They called me a wizard. They moved their schedules to watch me work. They passed it around. And then nothing.
A close friend, who I prepared personally by spending five days learning his profession so the demo would sit inside his actual work, was impressed and did not touch it again for two years.
I read that as a failure in people for a long time. I do not anymore. It is the fastest spreading technology in history and also the hardest one to actually grasp. It looks like a party trick, so you try it, it makes a mistake, and some part of you is relieved. Or you sit in front of the empty box and cannot think what to ask. Or you can, and the back and forth is tiring and looks like nothing from outside.
It was not that people could not. It was too early. It is just starting now.
But the result stands, and it is the most expensive thing I know: astonishment is not adoption, and a demonstration changes nobody. Three years of the most patient demonstration I could run produced almost no adopted practice anywhere.
That is why the training is a hundred hours and why it is in person. Not generosity. Findings.
Where the two halves met
I did not set out to build a platform. I set out to solve two problems for people I knew, and they turned out to be the same problem in different clothes.
Alan's problem was a body of work scattered into pieces the world cannot reassemble. The nonprofit's problem was AI arriving before anyone decided what it was allowed to touch. In both cases something was about to speak in their name, authoritatively, with nobody having decided what it could say.
The tool half without the training half hands an organization a capable machine and no formed judgment about it. The training half without the tool half gives you careful people and nothing to be careful with. I had watched both fail.
It also became clear that building for leaders and building for organizations is the same work. Leaders come first only because a leader can decide on a Tuesday and an organization takes a year.
Between September 2025 and April 2026 I built the platform, the agents, and the system underneath, working in context with Cursor and Claude Code, alongside a full time job for most of it. In March 2026 I went full time.
What I got wrong on the way
I had been building front ends fast enough that I assumed a full stack application would work the same way. It does not, and I walked straight into it.
A week into building a custom agentic CRM for the company I was working for, I gave a demo. It was bad. Not close. And I had spent two years training that room to expect a mobile app in a week.
Within days I went back and said we needed real timelines and real expectations, and we set them. What took months after that was not diagnosis. It was learning back end architecture from a standing start. Data, type safety, migrations, how an application actually holds and moves information. There was no map for that in 2025 and there still barely is.
I delivered in about six weeks against a three month timeline. It did not matter, because the room had decided in week one.
Two things came out of it. One is a rule I now keep: I do not test in public. I show it when it works. From outside there is no visible difference between this is hard and this was oversold, and I watch capable people hit that same wall constantly, including my own co-founders.
The other is the thing I would not trade. The same day it became clear I had to build a real data chain was the day it became clear I could build one from the prompt level. That idea is underneath everything I have made since, including the design work.
Sometimes you say you will be back in a week and it turns out to be a longer trip, and you come back with a map nobody had.
What it proved
Building for one real person beats building for a category. Everything good in the platform came from a specific problem one of those two actually had. Everything I built from a guess about what leaders in general would want, I threw out.
A grounded answer is worth more than a fluent one. Fluency is cheap now and it is about to be free. What will still be scarce in five years is an answer you can check, in a voice the person would claim.
The training is not the soft part. It is what the build is for. A tool without a formed person is not progress. It is replacement, and it arrives looking like help.
Still open
I do not know whether a hundred hours can ever be delivered at scale, or whether it only works when the person delivering it already knows the organization. Every engagement I have run has been with people I already had a relationship with, which means I have no evidence either way and a strong incentive to believe the optimistic answer. It is the open question that would most change the shape of the company, and I am not close to settling it.
If you have a body of work scattered across fifteen years of platforms, or an organization where AI showed up before the conversation did, I would rather hear about your situation than tell you more about mine. [Contact or newsletter line.]
How AI was used here. I built this software working in context with Cursor and Claude Code across about seven months. I wrote this piece. AI helped me gather notes and find things I had written elsewhere. The thinking, the argument, and the sentences are mine. Every number in it can be checked, and if you want to check one, ask me.
Before this publishes
Blocking, two. The build section, which is the reason a builder would read this at all and is currently a bracket. And the proof, which is one checkable thing: a link, a number with a date, or a capture. Without those this is a story about a build rather than a how-I-built-it.
Not blocking, four. What a training session actually looks like. What was happening at the nonprofit before anyone decided anything. The contact line. And the screen capture, which goes directly after the proof and is the cheapest credibility available to a builder.
Permission. The nonprofit is anonymous until the work is finished. The close friend should hear about this before he reads it.
The wrinkle is already here and it is good. What I got wrong on the way is the section that makes the rest of this believable. Do not let it get trimmed.