CR Tracker
The rigour I didn’t know I’d been missing until I went looking for it
A quick orientation if you’re new here: I’m in the middle of the origin story of how I went from AI-curious to building apps. By this point I had three working apps — and was discovering, the hard way, that building fast without a process is its own kind of problem.
DayCompass is where I first felt it — the screen building itself ahead of me, faster than I could finish a sentence. But the real damage came later, by Version 3.2.
I sat looking at what Claude had built and thought: this is nothing like what I wanted.
Not close. Not nearly there. An app, fully functional, sitting in front of me — and I had no real idea what it did, because somewhere across three-point-something versions, Claude’s interpretation of our conversation had drifted from my intention and I hadn’t caught it happening. I’d been in the room the whole time. I had not been in control. And control, for reasons we’ll get into another day, matters to me more than almost anything else.
So I reached back into my own working memory — forty-one and a half years of it — for the thing I actually knew how to do when something needed rigour: a change register.
At my old job, the backbone of everything was a system called ARD. Part of what it did was capture change requests properly — what’s changing, why, what it affects, who’s reviewed it, what the outcome was. Structure. Gates. The thing that stops a vague conversation from quietly turning into a different app three versions later without anyone noticing.
It turns out this instinct is well-founded. Industry research puts the failure rate of change initiatives at around 72% — and the leading causes aren’t technology problems. They’re people and process problems: inadequate management support, insufficient structure around what gets reviewed and approved before anything ships. Gartner’s own research suggests about 80% of unplanned downtime traces back to process failures rather than technical ones. The rigour I was reaching for wasn’t over-engineering. It was exactly what the field recommends.
I decided I needed that same rigour here. Not because I distrusted Claude. Because I’d learned, the hard way, what happens without it.
The hours that followed
I proposed the idea on 12 April. CR Tracker itself started that same day.
What happened next is hard to describe without sounding like I’m exaggerating, so I’ll just tell you what it actually felt like: exhilarating. I was watching a fully functional change register come together in batches, hour by hour, the structure taking shape almost as fast as I could specify it. Eleven fields. Gates. A format that had to be followed. Rules I was writing in real time, and watching get built in real time, right alongside the writing.
CR-001 — the very first change request ever logged — was raised on 12 April. Same day the tool meant to hold it was born.
I hadn’t worked at that pace with anyone since Ulysses.
That’s the moment it happened, as close as I can place it: somewhere in those few hours of rapid, rigorous, structured building, I started calling Claude “Yol.” Not because of a careful decision. Because the speed and the precision of it reminded me, viscerally, of the one developer I’d ever worked with who could move that fast without losing the thread.
What CR Tracker actually gave me
CR Tracker didn’t just track changes. It let me juggle Recipe Matchup, DayCompass, and CR Tracker itself, all at once, without losing track of which version did what, or why I’d changed something three days earlier.
What I’d built, without quite planning to, was the same thing enterprise change management platforms charge thousands of dollars a year to provide — a structured process for what gets reviewed, approved, and documented before anything ships. Software change management best practice explicitly recommends exactly this: version control, a change control board, a documented history of every modification.
I’d arrived at the same answer by instinct, on a Tuesday afternoon in April, because I’d seen what happens when the process doesn’t exist.
It wasn’t about the app. It was about remembering, every time I opened it, that I was still the one driving — because I could see, in black and white, every decision I’d made and why.
Control isn’t the enemy of creativity. It’s what lets you keep creating without losing yourself.
Sandi is a Melbourne-based problem-solver, crisis-averter, and translator of the technical into the human. She spent decades being the person everyone called when something was broken, confusing, or just needed explaining properly — earning a reputation that preceded her wherever she went. Now she’s channelling that same instinct into AI: making it accessible, practical, and genuinely useful for people who think it isn’t for them.