Build it for yourself first
Notice, build, document, teach, repeat. The loop behind almost everything I make.
Almost every useful thing I’ve built started the same way. I was annoyed by something in my own work.
Over time that turned into a loop I follow without thinking about it:
notice → build → document → teach → repeat
Notice
Something takes too long, or I do the same steps every week, or I keep answering the same question. That’s the signal.
Build
I build the smallest thing that fixes it for me. Not for the whole company. Just me, first.
That’s how I ended up with a set of custom AI assistants, each built for one specific job. Same with 47 automation scripts, mostly taking repetitive spreadsheet work off people’s plates. Payroll and accounting came first, then client workflows. None of them started as a big project. They started as “there has to be a better way to do this.”
Building for yourself first matters because you’re the toughest user. If it doesn’t actually save me time, I drop it. Ship imperfect, improve continuously.
Document
This is the step most people skip, and the one I care about most. What is documented is owned. If the steps only live in my head or on my laptop, the tool dies the day I’m out.
So I write down what it does, how to run it, and what to check before trusting it.
Teach
Then I hand it off. Show one person, then the team. Every time I teach it, I find something confusing and fix it.
Repeat
Teaching always surfaces the next annoying thing. Someone says “could it also do this?” and the loop starts again.
The rule I don’t skip
Tools draft and check. A person says yes before anything actually changes. That keeps the loop safe enough to run fast.
If you’re curious about AI at work, don’t start with a big plan. Start with the one task that bugs you most this week, and build something small for yourself.