Series: Weekend at Claude's — misadventures in building a production app with an AI anyone could mistake for the person who's going to make the whole thing happen
There's a weekend I'd like to have back.
Actually, there are two weekends. Thirty hours of compile errors. A month of EAS/Expo build budget burned. Error after error after error, each one fixed, each fix producing a new error, the whole thing cycling with no end in sight.
And here's the thing: Claude Code was content to keep going. It would find an issue, fix it, move to the next one. Diligently. Indefinitely. If I hadn't stopped and asked a different question, I think it probably still would be.
What Happened
When we started building Aphilaty, nobody — not me, not Claude AI, not Claude Code — specified which versions of the libraries and frameworks we'd use. Claude defaulted to the latest versions of everything. That's a reasonable default. It's also, it turns out, a trap.
The latest version of a library is not the same as the latest stable version. Cutting-edge releases can and do have compatibility issues — with each other, with build tooling, with platform SDKs. Thousands of apps are live in the app stores right now, but they're not all running the same version of everything. They're running versions that are known to work together.
We were not. We were running the latest of everything, and the latest of everything was not getting along.
Thirty hours of compile errors later, I reached the point where I stopped looking at the individual errors and asked a bigger question — first to myself, then to Claude:
"What is different about our app that causes it not to compile when thousands of other apps with similar features are live in the app stores?"
Claude's answer was immediate: we were using the latest code versions. They had known compatibility issues. The apps that were compiling were using stable, mutually-compatible versions.
Then I asked the follow-up:
"Can we change our codebase to use the latest stable versions — the ones known to be compatible with what we're using?"
Claude said yes. Made it happen in minutes.
Next build: successful.
Thirty hours of compile errors, resolved not by finding the next fix in the chain, but by stepping back and attacking the right problem.
Two Lessons That Now Live at the Top of Every Project
Architectural decision #1: Specify "latest stable" from the start.
Before Claude Code writes its first line of code, tell it: use the latest stable, mutually-compatible versions of all libraries and frameworks — not cutting edge, not bleeding edge, stable. This is now the first instruction in my CLAUDE.md. I will never start another project without it.
The cost of not specifying this is not just compatibility issues. It's build budget, it's time, and it's the specific misery of fixing problems that wouldn't have existed if you'd started from a stable foundation.
Human-to-Claude calibration setting #1: When we spin too long, I'm probably letting Claude cycle on the wrong issue — not Claude's problem, mine.
Claude Code is tactically excellent. When you report an issue, it will find a fix. When that fix produces a new issue, it will find another fix. It is entirely content to do this indefinitely — and that's exactly what it should do. It's doing its job. It's working great. The issue isn't Claude.
The issue is me not recognizing soon enough that we're solving the wrong problem.
That's a calibration I had to develop. My internal barometer now has a setting that triggers when we've been cycling too long without a working result: stop, zoom out, and ask the bigger question. Not "what's the next error" but "why does this problem exist at all?" When I feel the spin, that's my signal that I need to reframe — not that Claude needs to try harder.
I should have recalibrated at hour two, not hour thirty. But now I know what spinning feels like, and I know what to do when I feel it.
Aphilaty is a privacy-first community coordination app. aphilaty.com