152 Days of Building with AI: The Receipts
Five days into building my AI exec assistant, I asked it to write down what we’d done so far.
I thought it might be interesting to see what story it could tell about it’s own origin, just by reading git commits, scanning diffs, and scanning session transcripts.
What we did, what we learned, even the mistakes we made and how we corrected for them.
It was almost like a journal for a time-compressed collaboration between me and a machine that was learning my habits as fast as I was inventing them.
”Can I clone this?”
Soon after I started sharing my JFDI system more publicly, I’m getting the same questions over and over.
“Is there a github repo?” “Can I clone this?”
It’s not that I don’t want to share, it’s that I don’t think you can clone my system and get the same results.
The whole thing grew out of my specific problems, my specific workflows, my specific way of thinking about my business.
It’s “personal software” in the most extreme way, grafted on my world.
Are there lessons I can share? Absolutely.
Have I extracted pieces of my system to share? You bet.
But to get to where I am, it helps to start where I started.
Some people were annoyed by my answer, but most people understood and appreciated the encouragement.
And it was extra rewarding when people actually asked questions instead of wanting to skip the actual learning.
But I still wanted to offer more. And that’s when I remembered the log.
It was sitting right there in my repo. Eleven days of notes from when I was still figuring out the basics.
I realized this was actually the best answer to the question everyone was asking. Not “how do I build your system” but “how do I start building mine.”
So I cleaned it up, filled in the missing weeks, made the repo public, and set up an agent to keep it current going forward.
That’s how the andy-timeline happened. Not a content strategy thing. Just the best answer I had to a question I kept getting.
What’s in there
19 weeks. Each one gets its own chapter - what got built, what broke, what surprised me, what I had to tear apart and redo.
It’s not polished.
It reads like what it is: notes written while the work was happening, not after.
Some weeks are dense. Some are short.
The early weeks have this manic energy because everything was new and I was shipping constantly.
The later weeks are calmer because the system had started carrying some of the load.
A few things that jump out if you read it straight through:
The first week felt like magic.
I built the foundation in 11 days and it felt incredible.
That’s the part people see in demos.
It’s also the easy part, and if you stop there you’ve got a demo, not a system.
Weeks 2 through 4 were a grind.
Production hardening. Schema validation.
The kind of work that doesn’t make for good tweets but makes the difference between a thing you showed someone once and a thing you use every single day.
Day 48, I archived 37 scripts.
Rebuilt what survived as a modular skills system.
That single week changed everything that came after it.
Not because of what I added - because of what I got rid of.
And then somewhere around week 10, things started compounding.
Voice input, calendar sync, a memory system - each new piece made everything else work better.
My relationship tracker improved meeting prep. Meeting prep improved follow-ups. Follow-ups improved the relationship tracker.
You can actually watch that flywheel take shape if you read the weeks in order.
Why share it
Don’t try to copy what I have today.
Start where I started.
Build toward what your days actually need from you.
The timeline shows the whole path - including the parts where I got stuck, rebuilt things for the third time, and threw away stuff that wasn’t working.
That’s the part nobody documents because it’s not exciting while you’re in the middle of it.
But it’s also the part that makes the rest of it stick.
Here’s the whole thing: github.com/alexknowshtml/andy-timeline
If something useful shakes loose for you, I want to hear about it.