The Hidden Cost of Context-Switching Between Side Projects (And the Workflow That Ended It)

The expensive part of running several side projects is not the coding. It is the part nobody puts on a roadmap: sitting down Tuesday night to work on the project you last touched on Saturday, and spending the first fifteen minutes just trying to become the person who understood it.

I used to think my problem was time. Not enough hours, too many projects. So I optimized the obvious things. Cleaner repos. A task list. Tabs grouped by project. None of it touched the real cost, because the real cost was not in the doing. It was in the resuming.

The tax I was paying without seeing it

Here is the moment I mean. You open a project you have not looked at in four or five days. The code is yours, but it reads like a stranger wrote it. You stare at the function you were halfway through and ask the only question that matters: what was I actually doing here?

So you start excavating. You read the last few commits to remember what you finished. You scroll back through a task you wrote to yourself and no longer fully parse. You reopen the six tabs the project needs, the repo, the localhost, the docs page, the dashboard, and you wait for the shape of the thing to come back. Somewhere around minute twelve, it clicks, and you finally start working.

That gap has a name in psychology research: attention residue and the cost of resumption. When you leave a task, part of your attention stays stuck on the old one, and getting fully back in takes real effort. For a job you do eight hours a day, you rebuild that context once. For a side project you touch twice a week, you pay the full resumption tax every single session.

I did a loose count one month. I was actively working on four projects. Each one cost me roughly ten to fifteen minutes of pure re-immersion before any code happened. That is close to an hour a week spent doing nothing but reloading my own head. And the worse part was not the hour.

Why the heaviest projects rot first

The worse part was behavioral. Resumption cost is not evenly spread. The project with the most moving parts, the most stale context, the most "wait, where was I" is also the most expensive to reopen. So I started avoiding it.

Not consciously. I never decided to abandon anything. I just reached for the project that was cheap to resume, the one fresh in my head, and kept pushing the heavy one to "next week." Multiply that across a few weeks and the heavy project quietly dies, not from lack of interest but from resumption friction. The thing I most wanted to ship was the thing that felt worst to open.

Once I saw that pattern, the goal changed. I stopped trying to find more hours. I started trying to make resuming a cold project as cheap as resuming a warm one. If I could walk back into any project and be productive in under a minute, the avoidance loop would break.

What "resuming in under a minute" actually requires

I broke re-immersion down into the three questions I was answering manually every time, and treated each as a thing a tool should hand me instead of me hunting for it.

1. Where did I leave off? Not the task I planned. The work I actually did last. My memory of "I think I finished the auth refactor" is unreliable. The git history is not.
2. What is this project's working set? The specific tabs, repos, and dashboards I need open to be in the project, not adjacent to it.
3. How did I solve this last time? The config block, the snippet, the command I wrote three weeks ago and would otherwise rewrite from scratch or dig out of an old branch.

If those three are instant, the twelve-minute excavation collapses. So I built my workflow around answering exactly those three, in order.

The workflow that ended it

This is the actual sequence I run now when I sit down with a project gone cold. I use STACKFOLO, the project dashboard I build, because I needed this loop to exist and nothing I tried did all three. The principle matters more than the tool, so here is the loop itself.

Step 1: Read the last commits, not my memory. STACKFOLO pulls a GitHub commit timeline for each project into the dashboard, so the first thing I see is what I actually did last and when. "Three days ago: fixed the webhook retry. Before that: started the settings page." That single glance answers "where was I" before I open a single file. I wrote about the timeline side of this in more depth in how I track GitHub commits across all my side projects in one place; the difference here is that I now use it as a resumption trigger, not a progress report.

Step 2: Restore the working set in one click. Each project has a Quick Open preset, the exact group of URLs that project needs. The repo, the localhost, the Stripe dashboard, the docs. One click reopens all of them as a clean tab group. I am not rebuilding the environment tab by tab and accidentally dragging in three tabs from a different project. The project arrives whole.

Step 3: Reuse the solution I already wrote. The third question, "how did I do this last time," used to send me grep-ing through old commits. Now the config blocks and commands I reach for repeatedly live as snippets attached to the project, one click to copy. The deploy command, the seed script, the env template. I stopped rewriting things I had already solved.

Three steps, well under a minute, and I am working on a four-day-cold project as if I had touched it yesterday. The excavation is gone because the answers are sitting where I land instead of scattered across my memory, my tabs, and my git log.

What changed after a month of running it

The honest results, because vague wins are not worth writing down.

The hour-a-week resumption tax mostly disappeared. More importantly, the avoidance loop broke. The heavy project stopped being the one I dreaded opening, because opening it stopped being expensive. I shipped a feature on it I had been pushing off for six weeks, and the only thing that changed was that resuming got cheap.

I also stopped feeling like a worse developer than I am. A lot of the "I never finish side projects" guilt was not a discipline problem. It was a friction problem wearing a discipline costume. When the cost of getting back in dropped, the finishing followed.

If you run several projects and you recognize that fifteen-minute fog at the start of every session, the lever is not more willpower or more hours. It is making re-immersion cheap. Answer "where was I," "what do I need open," and "how did I solve this" instantly, and the projects you keep avoiding become the ones you actually ship. If you want the broader tooling picture, I laid out the best Chrome extensions for managing multiple side projects and how they map to each part of the switching problem.

Try STACKFOLO free on Chrome Web Store → chromewebstore.google.com/detail/stackfolo