I built a learning site for Alex. Podcast, flashcards, blog-post-style entries in my voice, the whole website in my voice. Needs heavy editing before it’s actually publishable, but the bones are there.
Alex is my husband. Alex is also a software engineer. I am not.
He has been watching me build Keiter & Co. from the outside for the last several weeks. Hearing me talk about specs and kickoffs and decision logs. Hearing me talk about Claude project instructions, CLAUDE.md files, decision logs that travel with every build, kickoffs that get handed off between phases. Occasionally asking what I’m working on. Mostly just trusting that I knew what I was doing.
At some point it became obvious that I had been moving so fast out of survival that I had forgotten to drag him along with me. If he was ever going to get the chance to start building the way I’ve been building, if he was ever going to learn the methodology, he needed a way into my brain.
With a toddler and an eleven month old who just started walking and can now get into everything, when do we have a chance to talk to each other? The ten minute drive to the grocery store, kids in the back, isn’t enough time to walk through how I want to learn a client’s business. It isn’t enough time to explain why kickoffs matter. It isn’t enough time to cover specs, decision logs, TODO files, VERSIONS files, and the constant rewriting of your own project instructions.
How does a one person company onboard another person when that other person is what has been keeping your house afloat and your kids alive while you’ve been building the business?
You build them a learning site.
writing it down taught me more than i thought
I thought I was capturing the methodology so Alex could learn it. What actually happened is I learned the methodology by capturing it.
I have been doing this work for weeks. I built the agents. I built the client dashboard. I built the portfolio sites. I wrote the specs, the kickoffs, the decision logs.
By the time I sat down to build the learning site, I realized that by capturing every decision across every build, keeping the specs, keeping the conversations, I had been building a methodology without realizing it. The trail was the methodology. I just hadn’t called it that yet.
I started the build the way I usually start a build. I opened a chat with Claude, listed what each module of the site should be, and started to fill in the content for each one. A few modules in, I stopped. There has to be a better way for Claude to get this onto paper than me talking through everything I have already talked through with Claude a hundred times. Everything I already have rules on. The work was already done. I just needed to point at it.
That is when I realized the decision logs were doing the heavy lifting. Not the conversation I was having in the moment. The trail.
I sat down to explain how a kickoff works and realized I had three different versions of it depending on which build I was looking at. I sat down to explain the stack and realized I had no idea why I chose what I chose, just that I had. I sat down to explain the naming convention and realized I had a fuzzy rule in my head and nowhere that rule actually lived.
Writing all of this down in decision logs is what made the methodology specific enough to teach.
the part that’s actually been teaching me
The reason I could build the learning site at all is because I’ve been writing things down for weeks. Every blog entry. Every Claude conversation I kept. Every spec, every kickoff, every decision log. None of it was filed in a way that screamed “future learning resource.” It was just the working notes of someone in the middle of building something.
That is exactly why it worked. The methodology didn’t exist as a document I could go transcribe. The methodology existed as a trail of specific decisions made in specific moments, written down because if I didn’t write them down I would forget them. The learning site is what happens when you compile the trail.
If I hadn’t been documenting this whole time, there is no learning site. There are no podcasts. There are no flashcards. There isn’t even a methodology to onboard anyone into, because the methodology is what I built by writing things down.
I have been learning by writing. I knew that in some vague way. I did not know it like this until I built a learning site and realized the learning site was less a teaching tool for Alex than a mirror for me.
caused me and claude to break up
Just kidding. But we did tussle.
On top of the methodology building itself, I was reminded of something I preach but clearly don’t always follow. Be specific. And keep keep keep updating your methodology, your CLAUDE.md files, your project instructions, your user preferences. Often.
I have been arguing with Claude for weeks about Alex. Not actually arguing about Alex. Arguing about the fact that I once mentioned, in a project instruction somewhere, that my husband is a software engineer. Claude took that and ran with it. Like ran a whole marathon.
Every time a build decision came up, every time a stack question landed, every time I was sitting there at 11pm trying to finish a spec, Claude would suggest I check with Alex. Confirm with Alex. Get Alex’s input on the hex codes. diD yOu aSK aLeX? 😒
Alex has not talked to the client. Alex does not even know the client’s name. Alex did not pick the hex codes. I picked the hex codes. I am picking the hex codes right now and at this point, simply out of spite, I am NOT asking Alex.
I will take my earrings off and fight you in the parking lot, Claude.
I did not fix it the first time it happened. I did not fix it the second time. I did not even fix it the third time. I finally fixed it the fourth time it happened, because the fourth time I was deep enough into the build that stopping to fix the instructions felt like less work than rerouting around the suggestion one more time. That is how project instructions actually get edited. Not when you notice the problem. When you can’t ignore it anymore.
The fix was specificity. I told Claude, in writing, in the instructions, that Alex and I are both 100% owners of Keiter & Co. Not 50/50. Not co-builders by default. Sometimes we work on the same things, often we don’t. Neither of us approves the other’s work. Mentioning that he’s an engineer was context, not a delegation chain.
Claude took the new instruction and stopped routing decisions to Alex. The fix wasn’t complicated. The lesson was: I had told Claude something true, and Claude had built an entire operating model on top of it that I never asked for. The only way to correct it was to be specific about what I actually meant.
Which is the same lesson the learning site taught me. You learn what you actually know by being forced to write it down precisely. The fuzzy version doesn’t survive when you need to teach someone how to be you without having the time to do so.
eureka
I want to talk more about the learning site itself, the technicalities behind it, and how I could replicate my methodology for someone else that needed something similar. But none of that right now is really what I want to get across.
What I want to get across is that I’m still learning how I learn. The writing is not simply documentation of the learning. It is also the learning itself.
The conversations with Claude where I’m trying to figure out what I’m trying to say are not preparation for the work. They are the work. The blog entries where I sit down thinking I have a clean idea and discover, three paragraphs in, that the actual idea is somewhere underneath, are not the polishing step. They are the step where I find out what I think.
I built a learning site for my husband and learned that I have been the student this entire time.
There will be more on the learning site itself. The technicalities, the modules, the things I figured out while building it, the things that broke and the things that worked. For now, I needed to get this eureka moment on the blog before it slipped past me.
find me on LinkedIn if the vibes feel right: linkedin.com/in/oliviakeiter
Leave a comment
Comments are reviewed before they appear. Email is optional and never published.