DEV Community: Henry Godnick

A bug-fix victory iPhone app blocker rule to stop doomscrolling

Henry Godnick — Fri, 31 Jul 2026 00:23:48 +0000

There is a weird doomscrolling window that shows up right after you finally fix something.

You chase a hard bug for an hour. The test passes. The build is green. The scary part is over.

Then your brain wants a reward.

That reward often becomes one quick look at TikTok, Reels, YouTube Shorts, Reddit, Hacker News, or whatever feed is closest. It feels earned, which is why it is dangerous. You are not avoiding work anymore. You are cashing out the relief.

The problem is that the app does not care that you only wanted a tiny reward. It is built to turn relief into another loop.

The rule

After a hard bug fix, do not open your phone for the first 10 minutes.

Not forever. Not all day. Just the first 10 minutes after the green build, merged fix, or passing test.

Use that window for one of these instead:

write the commit message
leave the PR note
update the issue with what actually broke
add the regression test you almost skipped
write one sentence about the root cause
stand up, drink water, and come back before opening anything

That sounds small, but it protects the moment when the reward-scroll reflex is strongest.

Why Screen Time is weak here

Apple Screen Time can tell you later that you spent 37 minutes in social apps after work.

That is useful, but it does not protect the exact transition where the habit starts.

The bug-fix victory scroll usually begins before you consciously decide to waste time. You are relieved. You are mentally tired. You tap the same app you always tap. By the time the report exists, the loop already won.

A better Screen Time alternative should help enforce the rule at the opening attempt, not only summarize the damage afterward.

What an iPhone app blocker should do for this pattern

For this specific loop, I think an iPhone app blocker needs three things:

App and website blocking, because the backup route matters
Open limits, because repeated tiny checks are the real pattern
Blocked-attempt logs, because seeing the attempts teaches you when the habit shows up

The website part matters more than people admit. If TikTok is blocked but the mobile site is open, the habit just changes doors.

The open-limit part matters because the first tap is often not the only tap. You might try again two minutes later without thinking.

The logs matter because they turn a vague feeling into evidence. You can see that your bad window is not random. It might be after bug fixes, after deploys, after code reviews, or after meetings.

A simple setup

If you keep losing time after wins, try this:

Pick the 2 or 3 apps that become your reward loop
Add the matching websites too
Block them during your main coding block
Keep the block active for 10 minutes after the expected end of a task
Review blocked attempts at the end of the day

The goal is not to become a productivity robot.

The goal is to stop giving the most vulnerable version of you full control over the easiest escape route.

Why I am building Monk Mode this way

I am building Monk Mode around the belief that distraction is not a motivation problem, it is an enforcement problem.

Monk Mode is an iPhone app blocker for people who keep losing time to automatic opens, social feeds, TikTok/Reels/Shorts loops, and backup websites. It supports hard app and website blocking, open limits, schedules, strict modes, challenge alarms, focus sessions, recovery analytics, and blocked-attempt logs.

If Screen Time keeps telling you what happened after the fact, and you want something stricter at the moment of the first tap, Monk Mode is here:

https://www.monk-mode.lifestyle/index.html#pricing

The practical test is simple: after the next hard bug fix, can your blocker protect the reward window before the feed opens?

A post-merge iPhone app blocker rule to stop doomscrolling

Henry Godnick — Thu, 30 Jul 2026 00:22:55 +0000

The most dangerous phone pickup is not always the one at night.

For developers, a sneaky one happens right after a merge, deploy, build, or ticket handoff.

You just shipped something. Your brain wants a small reward. You pick up your phone for "one quick check" while CI runs, logs settle, or the next task loads in your head.

That check can turn into TikTok, Reels, YouTube Shorts, Discord, X, Reddit, or whatever app your thumb opens before you think.

The problem is not that you forgot your goals.

The problem is that this transition has no enforcement.

The rule

After a merge, deploy, or task handoff, start a 20 minute focus session before touching the phone.

During that session:

block the social apps you usually open on autopilot
block their websites too, because Safari is the backup route
set an open limit for any app you still need to check
use strict mode if you know you will negotiate with yourself
make the unlock annoying enough that it interrupts the reflex

This is not about being productive forever. It is about protecting one vulnerable window.

The window is usually small:

merge done
dopamine spike
uncertainty about next task
phone pickup
feed loop

If the blocker catches step 4, the loop usually dies before it starts.

Why Screen Time often fails here

Screen Time is fine as a report card.

It is weaker as a real-time boundary because the bad moment is fast. By the time you are choosing "15 more minutes," the decision has already tilted toward the feed.

A better iPhone app blocker rule is situational:

after merging a PR
while a build runs
before opening Slack again
after closing the laptop for lunch
between two deep work blocks

The timing matters more than the total daily limit.

A simple setup

Make a list called something like post-merge scroll.

Add:

TikTok
Instagram
YouTube
Shorts and Reels routes if you use web fallbacks
Reddit
any social media blocker target that catches your reflex app

Then set the rule for the first 20 minutes after a ship or handoff.

If you still need your phone, keep utility apps available. The goal is not to brick the phone. The goal is to remove the feed path during the exact moment you are most likely to drift.

The metric to watch

Do not only look at total screen time.

Look at blocked attempts.

If you see 6 blocked attempts in the first 10 minutes after a deploy, that is useful data. It means the blocker caught the habit before you turned it into a session.

That is the whole point.

Distraction is not always a motivation problem. A lot of the time, it is an enforcement problem at a predictable transition point.

I have been working on Monk Mode around that idea: app and website blocking, open limits, strict modes, challenge alarms, focus sessions, recovery analytics, and blocked-attempt logs for people trying to stop doomscrolling on iPhone.

Link: https://www.monk-mode.lifestyle/index.html#pricing

A build-wait iPhone app blocker rule to stop doomscrolling

Henry Godnick — Wed, 29 Jul 2026 15:23:58 +0000

There is a specific kind of doomscrolling that happens while you are waiting for a build, deploy, test suite, codegen run, or app review task.

You tell yourself it is only 90 seconds.

That is enough time to check one feed.

Then the build finishes, but your attention is already somewhere else. You come back with the result on screen and your brain still inside TikTok, Reels, Shorts, Instagram, Reddit, YouTube, X, or whatever app you opened automatically.

This is the part people underrate about phone distraction. The damage is not only the minutes spent scrolling. It is the cost of switching back.

If you are trying to stop doomscrolling, one useful rule is to protect the waiting windows.

The build-wait block

Make a list of the apps and sites you open during short waits.

For most people it is some mix of:

TikTok
Instagram
YouTube
Reddit
X
Safari or Chrome fallback versions of those same feeds

Then create a short recurring block around the windows where you usually leak attention.

Examples:

First coding block of the morning
Right after lunch when you restart work
The last hour of the workday
Any scheduled deep work session
The 15 minutes before a meeting or standup

If your blocker supports focus sessions, start one before you run the command or begin the task. If it supports app and website blocking, block both the app and the browser version. Otherwise your brain will just route around the rule.

The goal is not to block your whole phone forever.

The goal is to block the reflex tap during the moment when your attention is easiest to steal.

Why this works better than a soft promise

A promise like "I will not scroll while this runs" still leaves the decision open.

That means you have to win the same argument every time there is a pause.

A real iPhone app blocker changes the default. When the build starts and your hand reaches for the phone, the feed is not available. That sounds small, but it removes the fastest escape route.

This is why I think distraction is often an enforcement problem, not a motivation problem.

Motivation helps you decide what matters. Enforcement protects that decision when you are tired, bored, or waiting.

Add an open limit for the apps you keep checking

Schedules are good for predictable work blocks.

Open limits are better for the "I just want to check once" habit.

A simple setup:

Allow 1 open of Instagram before noon
Allow 1 open of YouTube after work starts
Allow 0 opens of TikTok during focus sessions
Block the matching websites too

A time limit asks how long you stayed after opening the app.

An open limit catches the loop earlier, at the tap.

That matters because a lot of doomscrolling starts before you consciously decide to scroll. You are not choosing a 30 minute session. You are choosing a tiny check that becomes one.

Review the blocked attempts

The most useful signal is often the blocked-attempt log.

If you see blocked taps during builds, tests, meetings, before bed, or right after frustrating bugs, that tells you where to add rules.

You do not need a giant productivity system.

You need to find the small windows where your attention leaks, then make those windows harder to hijack.

For developers, build waits are a perfect starting point because they happen every day and feel harmless.

They are not harmless if they train your brain to leave the task every time there is friction.

If you want an iPhone app blocker built around app and website blocking, open limits, strict modes, focus sessions, and blocked-attempt logs, I am working on Monk Mode here:

https://www.monk-mode.lifestyle/index.html#pricing

The AI bill that made me build TokenBar

Henry Godnick — Thu, 16 Apr 2026 20:14:57 +0000

A few months ago I opened an AI bill that was bigger than it should have been.

Nothing was technically broken. That was the annoying part.

The problem was visibility. I could not tell what I was spending until after I had already spent it. By then the only option was to stare at the number and promise myself I would be more careful next month.

That is a terrible workflow.

So I built TokenBar.

TokenBar lives in the macOS menu bar and shows what is happening in real time. The point is not to make AI usage scary. The point is to make it visible while you are still making decisions.

That change matters.

When costs are hidden, people guess. When people guess, they overspend or underuse good tools because they do not trust the number.

I wanted a tiny tool that made the tradeoff obvious without getting in the way.

If you use AI every day and want cost visibility without opening another dashboard, TokenBar is for you.

The $1,200 AI bill that made me build TokenBar

Henry Godnick — Thu, 16 Apr 2026 20:06:17 +0000

I got hit with a $1,200 AI bill and my first thought was not "wow, great growth". It was "this is out of control."

I was using AI every day while building, but I had almost no feel for where the cost was coming from. The bill was high enough to be annoying and vague enough to be worse.

That is why I built TokenBar. Not to optimize for the sake of optimizing. Just to make the cost visible in real time, right in the menu bar, so I could stop guessing.

A lot of founder tools start as a pain you keep ignoring until it gets expensive enough to fix. This was one of those.

If you are building with AI and you have no idea what each day is costing you, that is a bad place to stay for long.

The AI bill was the first thing that made me build TokenBar

Henry Godnick — Thu, 16 Apr 2026 19:44:30 +0000

A few months ago I opened my AI bill and felt stupid.

Not because I used AI. Because I had no real feel for what I was spending.

The number kept climbing across tools, subscriptions, and little usage spikes. I could tell you the price of each app, but not the total cost of my workflow.

That gap is annoying when you are solo. You feel it late, after the bill lands.

That is why I built TokenBar.

It lives in the menu bar and keeps cost visible while I work. No dashboard hunting. No mental math. Just a quick reality check on what my AI usage is doing.

The lesson for me was simple:

If a cost matters, make it visible where the work happens.

TokenBar is for people who want that visibility without adding another tab to babysit.

If you have ever been surprised by an AI bill, you probably know the feeling.

Monk Mode: the mac app that blocks the feeds that eat your day

Henry Godnick — Thu, 16 Apr 2026 19:10:36 +0000

I made Monk Mode because the real problem is not apps, it's the default surfaces that pull you into scrolling.

Monk Mode blocks the specific stuff that turns a quick check into a lost hour:

YouTube Home
YouTube Shorts
X For You
Reddit front pages
other feed-style distractions

It is a Mac app, lifetime license, $15.

If you are trying to ship more and scroll less, this is for you: https://mac.monk-mode.lifestyle

I am curious what feed or distraction you would want blocked first.

I Stopped Treating AI Spend Like a Background Process

Henry Godnick — Thu, 16 Apr 2026 19:02:33 +0000

I used to treat AI spend like a monthly bill.

That was the mistake.

A monthly bill is something you inspect after the damage is already done. It arrives politely, with line items and a due date and just enough time to feel annoyed before you pay it. AI spend is not like that. It is more like a background process. It runs while you are coding. It runs while you are debugging. It runs while you are telling yourself, "I'll check later."

I learned that the hard way while building TokenBar.

I had the usual setup: a few models, a few tabs, a little too much confidence. I would open Claude or ChatGPT, ask for help, keep moving, and assume the cost was small enough to ignore. Then I'd look up later and realize I had spent another chunk of money without ever feeling the moment it happened.

That feeling is weirdly common for solo devs. You don't get a dramatic cloud bill explosion. You get a slow leak. A few dollars here, a few dollars there, and then one day you realize the product you built to move faster is also making your spending harder to see.

I didn't want another dashboard. Dashboards are where visibility goes to die. They are useful when you want a report. They are useless when you want a warning.

So I built TokenBar: tokenbar.site

The point was simple. Put the number where I already look. Right in the menu bar. Make it feel like battery life. Make it feel like temperature. Make it impossible to pretend I didn't know.

That changed how I work.

The first surprising thing was not that I spent less. It was that I started making better decisions before I started typing.

If I saw usage climbing, I would stop and ask: do I really need to paste this whole file? Can I narrow the prompt? Do I need the most expensive model for this? Sometimes the answer was yes. A lot of the time it was no, and the menu bar told me that before I had already burned the tokens.

The second surprising thing was psychological.

When AI spend is invisible, it feels abstract. When it's visible, it feels like part of the craft. You start noticing the cost of context. You start noticing the cost of retrying the same request three times because you were sloppy the first time. You start noticing that "just one more prompt" is never just one more prompt.

That has been the real lesson for me: the cost is not just the bill. It's the drift.

It's the drift between what you think you are spending and what you are actually spending.
It's the drift between "I'll keep an eye on it" and "I should have caught this yesterday."
It's the drift between a tool that helps you move faster and a tool that quietly becomes part of your overhead.

TokenBar exists because I wanted to collapse that drift.

Not with more analytics. Not with another beautiful graph. Just with a live, visible number in the place my brain already checks without thinking.

If you are building with AI and your costs still feel fuzzy, I get it. It is easy to ignore because the pain is delayed. But delayed pain is still pain. And for solo devs, ignoring it is expensive in the most annoying way possible: it feels small until it isn't.

I don't think every developer needs a token counter. I do think every developer needs a better relationship with what their AI usage is actually costing them.

That is why I built TokenBar.

If you want to try it, it's at tokenbar.site.

I built TokenBar because AI bills got stupid fast

Henry Godnick — Thu, 16 Apr 2026 18:09:14 +0000

I kept getting surprised by how fast Claude and Cursor usage could turn into real money.

So I built TokenBar, a tiny macOS menu bar app that shows live AI token usage while you work.

It is not trying to be a dashboard or another analytics rabbit hole. It is just a quick way to see what your AI tools are actually costing you before the monthly bill lands.

If you use Claude, Cursor, or any other token-heavy workflow and you want a simple guardrail, TokenBar is $5 lifetime:

https://tokenbar.site

Would love feedback from people who are actually watching their AI spend.

The $1,200 AI bill that made me build TokenBar

Henry Godnick — Thu, 16 Apr 2026 17:14:05 +0000

Last month I looked at an AI bill and realized I had no clean answer to one simple question: where was the money actually going? Not the total. The actual usage by app, by minute, by habit.

That gap is what pushed me to build TokenBar.

I wanted something that lives in the menu bar and tells me what I am spending on LLMs in real time. Not a dashboard I will forget to open later. Not a spreadsheet I will update on a good day. Just a constant, honest readout while I work.

The lesson was embarrassing but useful: small recurring costs are easy to ignore until they become a monthly ambush. AI tools make it even easier because the spend feels tied to productivity. Sometimes it is. Sometimes it is just drift.

TokenBar is my attempt to make the drift visible.

If you are a solo dev or a small team shipping with Claude, Cursor, or other AI tools, cost visibility matters. You cannot optimize what you are not watching.

If you want to see it, TokenBar is here: https://tokenbar.site

I am still building in public, still learning the hard way, and still trying to keep the product brutally simple.

I cut my Claude Code waste by 30% with one tiny menu bar tool

Henry Godnick — Thu, 16 Apr 2026 17:09:07 +0000

If you use Claude Code, OpenClaw, or Codex daily, token usage gets expensive fast and most of us have no live visibility while we work.

I built TokenBar for that exact pain: a lightweight macOS menu bar app that shows token usage in real time while you code.

What changed for me:

I stopped over-prompting and started batching asks
I could see which sessions were silently expensive
I made better model routing decisions earlier

If you are deep in AI-assisted dev and want cost awareness without dashboards, this is a simple add-on.

Price: $5 lifetime
Site: https://tokenbar.site

Happy to share a setup screenshot if useful.

The day my AI bill punched me in the face

Henry Godnick — Thu, 16 Apr 2026 15:43:14 +0000

Last month I opened an AI bill and had that quiet founder moment where you realize the problem is not theory anymore.

It was real money, real waste, and it was coming from my own product and workflow.

The part that bothered me most was not the total. It was how invisible it had become.

A few things were quietly driving the bill up:

duplicate loops
overly expensive models on simple tasks
retries that looked harmless in the moment
enough small usage spikes to hide the damage until the invoice arrived

That is why I built TokenBar.

I wanted a dead simple way to see token usage and cost in real time, right where I work. Not after the month ended. Not in some dashboard I will check later. Right now.

The lesson is bigger than AI costs.

If you cannot see what something is costing you, you will overuse it.
That applies to money. It applies to focus. It applies to attention.

The same instinct is behind Monk Mode too. Remove the noise. Make the cost of distraction visible. Make the right behavior easier.

If you are shipping with AI every day, audit your usage early. The bill is never just a bill. It is feedback.

TokenBar helps me catch the spikes before they snowball.

If this is your pain too, you are not alone.