For more than a decade, my mornings began with Firebase Crashlytics. I have been building apps on my own since 2014, and opening that dashboard before coffee had become as automatic as putting on my glasses. On a calm morning it took thirty seconds. On a worrying morning it stretched to thirty minutes. As cumulative downloads passed the 50 million mark across the Beautiful HD Wallpapers series and a handful of healing apps, the gap between those two states became harder to predict, and the rhythm of my day was quietly being eroded by it.
In early May 2026, I started running Claude in Chrome in a corner of my development machine. The first thing I asked it to take over was that morning ritual. Not full automation, but a weekly review: once a week, I let Claude in Chrome walk through Crashlytics dashboards across my apps, and I focus only on the parts where human judgement is required. After two weeks of this loose division of labor, the texture of my days has shifted more than I expected, so I want to write it down while the impressions are still fresh.
Why I wanted to move from daily checking to a weekly review
The daily checking habit held a mix of rational and irrational reasons. In the first 48 hours after a release, daily inspection genuinely maximizes the chance of catching a critical crash early. Once an app has been live for several days, however, about seventy percent of newly reported crashes come from older OS versions or extremely narrow device combinations that do not require an immediate fix.
As an indie developer I currently maintain more than ten apps, including the Beautiful HD Wallpapers titles and a number of healing and manifestation apps. Even when the check itself is short, the cost of context switching adds up across that many products. Continuing to balance art practice with indie development meant I needed to compress that scattered-attention time. That was the starting point for this experiment.
What I delegate to Claude in Chrome, what I keep on my own desk
The first thing I clarified was that Claude in Chrome is an assistant, not a supervisor. Crashlytics decisions depend on the history of past fixes, app-specific quirks, and signals that arrive through direct user messages. The moment I try to hand all of that to AI, the quality of the decisions drops, and I lose the felt sense of how each app is doing.
So the split looks like this. Claude in Chrome takes over the navigation work: opening each app's Crashlytics page in sequence, scraping the count of new crashes, the number of affected users, and the top five lines of each stack trace, and assembling them into a single Markdown table. I run this once a week, on Saturday morning.
I keep the decision work for myself. Sitting with that table, I decide whether each issue needs an immediate hotfix, can wait for the next regular release, or can be deferred indefinitely. The point is not to let Claude decide; the point is to let Claude prepare the materials cleanly so I can decide without losing focus.
Three changes I noticed after two weeks
Week one was mostly about getting used to Claude in Chrome's behavior and getting over my own resistance to skipping the morning check. By the end of week two, three things had clearly shifted.
The first was the quality of my decisions. When I looked at Crashlytics every morning, I was unconsciously comparing today against yesterday. With a weekly review, I look at seven days of cumulative data at once, and that naturally gives me a sense of denominator — how many incidents this crash actually caused in a week.
The second was the stability of my priorities. With daily checking, I would sometimes start working on whichever crash I happened to see first that morning, even when a more serious crash was sitting one tab over. The Markdown table from Claude in Chrome sorts the issues by impacted users, so I now start from the top and stay there.
The third was the easier transition between art practice and indie development. Ever since I taught myself programming in 1997, technology and expression have lived on the same continuum for me. But opening Crashlytics flips my mind fully into "indie developer mode." When I did that every morning, my quiet creative hours were already being interrupted before they began. Switching it to once a week gave that quiet morning back to me.
Where I almost rolled back
This makes the experiment sound smooth, but more than once during week one I considered reverting.
The biggest stumble was that I temporarily forgot my own 48-hour-after-release rule. Right after switching to the weekly review, I shipped an update that introduced a crash specific to certain Android 14 devices. I missed it for almost two days. The affected user count stayed under ten and I caught it in time, but under the old routine I would have noticed it the very next morning.
After that I tightened the operational rules:
- For the first 48 hours after a release, I do not delegate to Claude in Chrome — I keep the daily visual check.
- Once an app is past that 48-hour window, it moves into the weekly review.
- If Crash-free Users drops below 99.7% for any app, Claude in Chrome sends me an immediate alert without waiting for the weekly slot.
The alert is a lightweight combination of Claude in Chrome on a schedule and a Slack notification. The implementation deserves its own post, but the principle has not changed: humans decide, AI detects.
What it feels like to let Claude "open the browser"
Pulling Crashlytics data through an API would arguably be cleaner. The reason I deliberately chose to have Claude in Chrome open the actual screens is that I wanted to keep the workflow inspectable. I could peek in from the side at any time and see exactly what Claude was looking at.
Something I absorbed from both of my grandfathers, who worked as temple carpenters, is that I want to keep my hands close to whatever I am building. Fully automated pipelines tend to become opaque once they have run for a while — even I have trouble remembering where to look first. With browser tabs left open, I can always step back into the same view with my own eyes.
That sense of "I can return whenever I want" is hard to quantify, but it noticeably keeps me willing to continue running the system. After 12 years of balancing art and indie development, I have come to trust that the systems I cannot touch do not last in my hands.
What is next
A few areas remain on the to-do list. Two are at the top.
The first is cross-referencing with AdMob reports. If days with crash spikes line up with days when eCPM drops, having Claude in Chrome check both side by side once a week would let me catch revenue impact earlier. I have written before about AdMob mediation comparisons, and there is still operational work left to do there.
The second is cross-referencing with English-language support messages. Crashlytics often picks up signals without any user ever reporting them; conversely, a user message sometimes lands before the crash count climbs in the dashboard. Having Claude in Chrome line up both sources should reduce the chance of missing either.
Letting go of a daily habit I had kept for twelve years took some courage. After two weeks I am not tempted to go back. If you are also feeling that the morning dashboard check is borrowing time you would rather spend on something else, I hope these notes are useful. Thanks for reading.