The Solo Developer Problem Nobody Talks About: Cognitive Load

The hardest part of running many projects isn't coding. It's remembering everything.

I manage 50+ repositories and 27 domains. I've been building side projects, SaaS tools, client work, and experiments for years. People ask me about my stack, my deployment setup, my productivity system. Nobody asks the question that actually matters: how do you keep all of it in your head?

The answer is I don't. And for a long time, that was the problem.

The tax you can't see

There's a concept in software architecture called cognitive load -- the amount of mental effort required to understand and work with a system. Teams talk about it when designing microservices. Nobody talks about it when you're a solo developer running a portfolio.

Here's what it actually looks like.

You open a project you haven't touched in three months. The code makes choices you don't understand. Why did you use a custom auth flow instead of Supabase Auth? Why is there a weird caching layer in front of a database that gets 200 requests a day? Why is this component structured so differently from the same pattern in your other projects? The decisions made perfect sense at the time. You probably spent an afternoon researching the tradeoffs. But the reasoning is gone. All that's left is the code, and the code only tells you what, never why.

You forget what's deployed where. Is cullr on Cloudflare Workers or Vercel? Does istqb-app use Supabase or its own Postgres? Which projects are on the free tier and which ones are on paid plans that are silently charging you? You'd think you'd remember this. You don't. Not when the number gets past ten or fifteen.

You forget configuration details. What's the deploy command for this one? Where are the env vars stored? Is this the project where you need to run a build step before deploying, or does the CI handle it? You've set up deploy pipelines dozens of times, and every single one is slightly different, and you can never quite remember which variation this particular project uses.

And then there's the AI tax. Every time you start a Claude Code session, you re-explain your world. "This project uses Next.js 16 with Supabase Auth. The API routes are in src/app/api/. We deploy via git push to Vercel. The database has this specific schema quirk because of a migration I ran in January." Every single session. Multiply that by 50 projects and several sessions per day. You become a human context server, endlessly feeding the same information to agents that forget everything the moment the session ends.

Context switching is where it gets really expensive. Going from one project to another takes 20 to 30 minutes of pure loading time -- not writing code, not making progress, just re-building the mental model. What was the data model again? How does the auth flow work? What was I in the middle of last time? It's like swapping a virtual machine into memory, except the VM is your understanding of an entire codebase and you have to do it by reading code and squinting at old commit messages.

The decisions you never make

The visible cost is the time spent remembering. The invisible cost is worse: the things you don't do because the cognitive overhead is too high.

You don't upgrade dependencies because you'd have to figure out the test setup again. Is it Vitest or Jest? Does it use a test database? Is there a setup script you need to run first? The upgrade itself takes five minutes. The context loading takes thirty. So you don't do it, and the CVEs pile up.

You don't fix that bug a user reported because you'd have to re-learn the data model. The fix is probably two lines. But finding those two lines requires understanding how the schema works, how the API routes are structured, and which edge case the user hit. The cost of context is ten times the cost of the fix.

You don't add that feature you've been thinking about because you've forgotten how the deployment pipeline works. You know it's possible. You know it would make the project better. But the activation energy of loading all the context back into your head is higher than the motivation to build the thing.

This is how projects die. Not because they're bad ideas. Not because they lack users. Not because the code is unmaintainable. They stagnate because the context cost of working on them exceeds your willingness to pay it. Every month that passes, the cost goes up. The code gets less familiar. The decisions get hazier. The deployment details fade. Eventually a project crosses the threshold where it's cheaper to rewrite it than to understand it. That's a failure of memory, not engineering.

What actually helps

I've tried everything. Notion databases. README files. Architecture decision records. Obsidian vaults with links between notes. They all share the same fatal flaw: they require you to maintain them, and nobody maintains documentation for 50 side projects.

You write a beautiful README when you start a project. You update it once, maybe twice. Then you're heads down building, and the docs drift, and six months later the README describes a version of the project that no longer exists. Documentation that lies is worse than no documentation at all.

What I've found works is a different approach entirely.

Decision logs over documentation. Instead of maintaining a living document that describes the current state (and inevitably falls behind), write down decisions at the moment you make them. "Chose Supabase Auth over custom JWT because X. 2025-11-14." These entries are immutable. They don't go stale because they describe a point-in-time choice, not a current state. When you come back six months later and wonder why the auth flow is weird, you find the entry and the reasoning is right there.

Automated context generation. The state of a project -- its architecture, its dependencies, its deployment setup -- can be derived from the code itself. Schema files, package.json, CI configs, infrastructure-as-code. A system that reads these artifacts and assembles a structured summary gives you 80% of the context you need without anyone having to write or maintain anything.

Capture with zero friction. The reason I don't write things down isn't laziness. It's friction. If capturing a thought takes more than three seconds, I won't do it. I'll tell myself I'll write it down later, and I never will. The insight stays in my head, inaccessible to my future self and invisible to any AI agent. The capture surface has to be ruthlessly fast. A voice note while walking. A text message from my phone. A CLI command while I'm already in the terminal. If I have to open an app, navigate to the right page, and format my input, the knowledge is lost.

Expiring knowledge. Most of what you capture isn't worth keeping forever. That debug insight is relevant for a month. That deployment workaround matters until you fix the underlying issue. If captured knowledge doesn't expire by default, you end up with a junk drawer that grows until it's unsearchable. Everything should have a time-to-live. If it proves its value, it gets promoted. If it doesn't, it disappears. The system stays clean because staying clean is the default, not the exception.

The goal isn't perfect recall

I don't need to remember everything. I need to reduce the loading time between projects from 30 minutes to 30 seconds.

That means when I open a codebase, the context is already there. Not in my head, but available. The architecture decisions. The deployment setup. The recent changes. The known issues. The conventions. All of it structured, current, and readable by both me and the AI agents I work with.

I built a system that does this. It captures knowledge from wherever I happen to be -- voice, text, webhooks, email. It classifies and routes each fragment to the right place. It generates structured context files that sit inside each project repo where any coding agent can read them. The details of the system aren't the point of this post. The point is the principle: your memory is a bottleneck, and you can engineer around it.

The real ROI isn't time saved. I can't honestly claim I save hours per day. What I save is cognitive load. I stopped waking up wondering what's broken. I stopped spending 20 minutes remembering how each project works before I could write a single line of code. I stopped avoiding projects because the context cost felt too high.

The system remembers for me. And that changes which projects I'm willing to work on, which bugs I'm willing to fix, which features I'm willing to build. Not because I have more time, but because I have more capacity. The mental overhead that used to consume my first hour every morning is just gone.

That's the solo developer problem nobody talks about. Not the coding. Not the shipping. Not the marketing. The remembering.

Solve the remembering and everything else gets easier.