Building the Machine Is the Easy Part
For the first year and a half, my therapist-matching company Butler didn't have an algorithm behind it. I did it by hand, manually.
There was no matchmaking standard in the industry and no dating algorithm to copy the logic from yet. I interviewed a lot of people, but no one could tell me, "Here's what matters." Rather than automate a guess, I did it myself, one person at a time, deciding who went with who.
I would do it the same way today.
Right now, the story around AI promises that manual work is over. Your time can all go to thinking and creating.
At its core, I agree with that promise. You don't have to work yourself to the bone to create a beautiful, durable company. Your job is to build the machine, not be the machine. But you can't build a machine if you don't know the rules it runs on.
That's where the promise is wrong. The year and a half I spent matching by hand wasn't the time before Butler had an algorithm. That was the algorithm being written.
The manual work is where the machine comes from. When you've done the work yourself, building the system is just the documentation of what you already know. Without the manual work, building gets complicated and lengthy.
While some systems are just a trigger and a list of steps (when someone enrolls in one of my cohorts, tag them with the cohort, tag that they paid, tag where they came from, ping me in Slack), more complex systems hinge on the places where you have to stop and make a judgment call.
If you haven't run the process yourself, multiple times over, you won't know where those places are, what call gets made, or why. You'll build quickly and then get stuck patching something that works in theory and not in reality.
This just happened to a founder I work with. She's building software that turns dense specialist reports into a plain-English plan that an ordinary person can act on. Part of that involves weighing test findings and deciding which ones matter. She handed that piece to an AI coding agent.
She had the idea for the product when she was trying to understand one of these reports herself and had to translate it line by line into something that made sense. Before starting with the coding agent, she read textbooks and studied how the tests were supposed to work. Between the two, she knew how the system should run.
On the report she used to build it, it ran beautifully. But when she started running other people's reports, it snagged.
Every specialist uses different tests and rates severity on a different scale. Within a single document, a high score might mean good in one section and bad in another. Having learned the scoring one way, the agent applied that standard everywhere. It read a bad result as a good one and told the person there was nothing to worry about.
This founder had done her research, but because she hadn't sat down with a stack of other people's reports and actually produced her product again and again, she didn't know where reality broke from theory.
When it happened and the model started producing wrong answers, she caught it and fixed it. Then something else broke, so she fixed that too.
Each failure was small, so she patched it. But every patch added a rule, and the rules started contradicting each other. Because each one made the symptom go away, she couldn't tell she was accumulating a mess. Eventually she couldn't say when the system had last been correct and needed a second model to find where it started degrading.
When you build through fixing, you're not learning how the work goes, you're steering back toward the system you imagined. When you work by hand, you're not fixing anything. There is no system to patch. Instead, you're finding out how the work actually gets done. The structure of the system shows up on its own once you've done the work enough times. Often, it's not what you imagined.
At Joany, I had a similar problem to that founder's. Claim and benefit data weren't standardized, so telling someone what they really had to pay and what they were getting for it was incredibly difficult.
I decided to standardize the documents in order to make it easier. As I worked, I kept making the same call: Do I take this number, or do I go digging? The decision was always based on which carrier the document came from.
I would have assumed I'd find patterns across the documents to help me, but the pattern showed up in the carriers. Some carriers consistently spelled everything out, and others never did. So I started scoring them. A five meant I could take whatever a carrier sent at face value and never re-check it. Anything below that I had to translate and dig through.
When I automated the process, I didn't build a mess of rules around how to standardize all the documents. I built a system that used the carrier the document came from to sort which ones we had to verify by hand and which ones we didn't.
I didn't design that system and I couldn’t have guessed it. I found it by going over those documents one after another, by hand. It took time, but once I had the system, the build was straightforward.
Here's what I'd do this week. Pick the one process you most want off your plate. Screening candidates, chasing quotes, deciding which leads get a call. Whatever came to mind first.
Go do it yourself, start to finish. Write down the steps as you go, literally what you did. Then mark every point where you had to stop and make a call. What was the call, and what were you weighing?
Then do it again, and again, until you catch yourself writing the same line for the third or fourth time. That's your first real rule, and you should be able to say it in one sentence. This vendor never gives us the number until we ask twice. A candidate who reschedules the first interview doesn't take the job.
Now you have something to hand over. But don't just give the model the rule, tell it what you've done before, where it didn't work, every time it did, the edge cases. That's what turns a model that follows your steps into one that makes your call.
A system that's built on a description of the work can be built quickly. But only something built on how things really get done will consistently work.
At Butler, I put in the time to understand what mattered in a pair. When the same considerations kept showing up, I articulated them as matching rules. I made a simple intake questionnaire and wrote the matching rules into the software.
After I'd found the rules, my job was done. The software part was straightforward. I already knew it would work because it was exactly what I'd been doing, just without me there.
Tell me a rule you only found by doing it yourself. The one you could have only found through experience. Reply or comment, I read every one.
-Christine
If you want to go deeper
Here's where to start:
⚫️ Private Coaching: for early and growth-stage entrepreneurs who want to lead with more clarity while increasing their resiliency. See if we're a good fit here.
⚫️ The 20 Hour CEO Self-Paced Course: The frameworks, systems, and playbooks to stop being the bottleneck — on your schedule.
⚫️ The 20 Hour CEO Live Cohort: 3 weeks, 6 live sessions. Bring your actual business, rebuild how it runs, and leave with systems already in motion.
