Interrupting Infinite Loops
When the Feed Never Says Done
Here's a question worth pausing on: when was the last time an app told you that you were finished? A book has a last page. A show rolls its credits. Even a newspaper eventually runs out of pages. But your feed? It refills the instant you reach the bottom, so the bottom never comes.
This is infinite scroll, a design pattern that quietly removes the natural stopping points older media always had. Those endpoints used to do your deciding for you. When the article ended, you looked up. When the episode finished, you stood up. Now nothing ends, so nothing prompts you to stop, and the decision to quit gets handed entirely to you, in the middle of a stream engineered to feel like there's always one more thing worth seeing.
The same trick hides in a less obvious place: repeated response-checking. After you send a message or post an update, you circle back to see who replied, who reacted, who noticed. Nothing signals "that's all the responses you'll get," so you check, then check again, waiting for a finish line the system was built never to draw. Notice the shared pattern: neither one hurts you with a single glance. Both work by erasing the moment where you'd naturally say "done."
The Loop That Opens the Moment You Post
So think about what happens when you share something at work: a project update, a quick win, a comment in a team channel. The instant it's out there, a new loop opens. This is a validation loop, where each like, comment, or reply trickles in unpredictably, and every one of them tugs you back to look.
Why so sticky? Because you're not waiting for information you need, you're waiting to learn how people reacted to you. That anticipation is the hook. And since reactions land on their own schedule rather than yours, the app never announces the results are in. You posted twenty minutes ago and got three reactions; could a fourth be sitting there now? The only way to know is to check, which is exactly the behavior the loop rewards.
- Chris: I posted a project update this morning and I've refreshed it, I don't know, ten times since.
- Natalie: What are you waiting to find?
- Chris: More reactions, I guess. But honestly the report I owe is just sitting there.
- Natalie: So when will you know you've checked enough?
- Chris: Huh. There's no point where it says "okay, that's everyone." It just keeps going.
- Natalie: Right. The loop won't close itself. That's the whole design.
Watch what Chris catches: the loop has no built-in ending, so it runs as long as he lets it. Naming that is the first move toward stepping out.
Building the Finish Line Yourself
Here's the uncomfortable implication: if the feed will never tell you when you're done, then either you decide the endpoint or you don't get one. There's no third option. So the move isn't willpower, it's design. You supply the stopping point the app deliberately left out.
Two pieces make an endpoint you can actually keep. The first is a stopping cue, a clear signal that ends the session: closing the app after a single check, reaching the bottom of one screen, or a timer chiming. The second is a timebox, a set amount of time or a set moment for checking, decided before you begin. For a posted update, that might mean one two-minute check at a planned time, then the app stays closed until the next window. For scrolling, it might mean one screen, or two minutes, then out.

The point isn't to check nothing. It's to make "done" a decision you make on purpose instead of one the app keeps postponing. An endpoint you can see and repeat beats a vague promise to "check less," because "less" has no finish line either. So ask yourself before you open anything: what will tell me I'm finished here? If you can't answer that, the app has already answered it for you, which is to say, never.
The single idea to carry out of this unit: infinite scroll and validation loops keep you hooked by deleting the moment you'd naturally stop, so protecting your attention means drawing that line yourself. Next comes a quick pattern-spotting check to pin down exactly which design feature keeps a feed from ever signaling "done." As you go, sit with this: of everything you check today, how many have an endpoint you chose, and how many just run until something interrupts them?
