DEV Community

Hoa Trinh
Hoa Trinh

Posted on

I kept abandoning side projects, so I built a tool to fix the real problem

I have a graveyard of side projects. Not dramatic failures, just apps that quietly stopped.

A habit tracker I was genuinely excited about. A recipe manager I used every day for two weeks. A CLI tool that was 80% done. All of them died the same way: I stepped away for a few days, came back, stared at the code, and thought, "I'll pick this up tomorrow." Tomorrow never came.

For a long time, I assumed this was a motivation problem. I tried fresh starts, cleaner task lists, and better scoping. None of it stuck.

Then one evening, I opened a project I hadn't touched in ten days. I spent the first twenty minutes just reading my own code, trying to reconstruct what I'd been doing. By the time I pieced it together, I didn't have the energy to actually build anything. I closed the editor and watched YouTube instead.

That's when it clicked: the problem wasn't motivation. It was context.

The 15-minute problem

Here's what actually happens when I try to resume a side project after a break:

I sit down with ~45 minutes. Good energy, ready to build. I open the project. I scan recent commits. I check the current branch. I re-read the code I was writing, trying to remember what I was thinking. I open the issue tracker to see if I left myself notes.

Twenty minutes later, I finally have enough context to start. But half my session is gone, and I spent it on archaeology instead of building.

That friction compounds. Eventually, the cost of resuming becomes just high enough that you choose something else instead. Not consciously. You just… don't open the project.


It's not motivation. It's context loss.

I started calling this context debt: the mental state that evaporates when you step away from a project.

  • Git tells you what changed, but not why you were changing it.
  • Your task list tells you what's left to do, but not where you were in the middle of doing it.

The cost of resuming after a break is what actually kills most of my side projects. Not the building, the coming back.

Once I saw it that way, the problem statement became pretty clear:

How do I make it almost effortless to pick up where I left off?


So I built a small tool

I ended up building a VS Code extension called KeepGoing. It's basically a thin context layer for your projects.

The idea is simple: capture lightweight "what was I doing?" context while you work, and hand it back when you return, without asking you to maintain docs for your future self.

This isn't meant to be a full-on productivity system. It's closer to a memory prosthetic.

Here's how it works in practice.

KeepGoing Demo

1. You code normally

No setup ritual, no new workflow. You open your project and code like you usually do. KeepGoing runs in the background.

I didn't want something that turned into its own todo app or forced me to remember another step before closing my laptop. If it required discipline, I knew I wouldn't use it.

2. Context gets captured automatically

KeepGoing watches for natural breakpoints and saves small "checkpoints":

  • On every git commit, it captures what you were working on
  • On branch switches, it snapshots context before you shift focus
  • After inactivity (75 minutes by default), it saves where you left off
  • You can also hit Cmd+Shift+K anytime to save a quick checkpoint manually

Each checkpoint records things like:

  • A short summary of what you were doing
  • The next step you had in mind
  • Any blockers
  • Which files you touched
  • Which branch you were on

All of this is stored as readable JSON in a .keepgoing/ folder in your project root. No external service, no account, nothing fancy.

3. You come back and actually know where you were

When you reopen a project after a break, KeepGoing shows a small sidebar briefing:

  • What you were doing last time
  • What you planned to do next
  • Which files matter for that work

If you've been away for 24+ hours, it proactively shows a "cold start" summary so you don't have to go hunting for it.

The experience I was aiming for is:

Open project → read a 2–3 line snapshot → jump straight into the right files.

No commit archaeology. No "wait, what was this branch for again?" Just enough context to unpause.


The "why" problem

After using this for a while, I ran into another gap.

Checkpoints are great for short-term intent and next steps. But some changes are more long-lived: CI configs, OAuth setups, database migrations, deploy scripts, etc. Those are the ones where, three weeks later, you look at your own code and think, why on earth did I do it this way?

So I added a feature I call Decision Detection.

It does two things:

  1. Identifies "high-signal" commits: infra, auth, migrations, deploy scripts, that sort of thing.
  2. Prompts you to jot a quick rationale, just a few sentences on why you made that call.

If you ignore the prompt, it still saves the decision as a draft so you can fill in the details later. The goal isn't perfect documentation; it's just capturing the important "why" before it evaporates.

The core checkpoint system is free; Decision Detection is a one-time paid add-on. I'm mentioning it for completeness, not trying to pitch it.


Plays nicely with AI agents

Agentic coding tools can already scan your repo and infer what's going on. But even with decent AI helpers, I kept finding the missing piece wasn't more code suggestions, it was remembering what I cared about last time I touched the project. AI can summarize files; it can't remember what future-me would have considered "done" for a feature.

Good, human-authored context makes AI agents better too. So I built an MCP server that exposes your checkpoints and decisions to compatible tools. When you start a new session, the assistant can see:

  • What you were working on last
  • What you planned to do next
  • What architectural decisions you've already made

No huge prompt paste, no "let me read through your recent commits for you." It just starts from where you left off.

Setup is literally one command:

claude mcp add keepgoing -- npx -y @keepgoingdev/mcp-server
Enter fullscreen mode Exit fullscreen mode

There's also a CLI if you live in the terminal. You can add a shell hook so that whenever you cd into a project, it echoes your last checkpoint. That's been surprisingly helpful for me.


Design constraints I cared about

When I was building this, I had a few non-negotiables:

  • Local-first. All data lives in .keepgoing/ in your project. No cloud, no accounts, no syncing.
  • No gamification. No streaks, no guilt, no "you haven't coded in 3 days" notifications. This isn't meant to judge you. It's just context.
  • No subscriptions. The basics should be free. If there's a paid part, it should be a one-time thing.
  • Privacy by default. .keepgoing/ gets auto-added to your .gitignore so you don't accidentally commit your workflow notes.

Basically, I wanted something I'd actually be comfortable running on all my personal projects.


You don't need more hours. You need less friction.

Most side projects don't fail loudly. They just… stop getting opened.

In my case, it wasn't a lack of ideas or a lack of skill. It was the invisible tax of context switching, having to rebuild my mental state every time I came back after a break.

Using KeepGoing on my own stuff for the last few months has made a noticeable difference. Coming back after a week off used to feel like starting over. Now it feels more like unpausing a game.

I open the project, the sidebar pops up, and I see something like:

"Was refactoring the auth flow; next step is updating the callback handler and testing with provider X."

…and I'm usually writing code again within a couple of minutes.

That's really all I wanted out of this: make the resumption tax as close to zero as I can, without turning my side projects into process-heavy work.


If this resonates

If you've also got a side project graveyard, or you've felt that weird resistance to reopening an old repo, you're exactly who I had in mind when I built this.

You can check it out here if you're curious:

But mainly, I'd love to hear how you deal with this yourself:

  • Do you leave notes to future-you somewhere?
  • Do you rely on commit messages?
  • Do you just accept the 20-minute "what was I doing?" cost?

I'm still actively iterating on this, so any stories, ideas, or "here's how I've hacked around this" comments are very welcome.

Top comments (0)