The solo developer's toolkit: tools that actually help you ship

There are a thousand “best developer tools” lists on the internet. Most of them are sponsored, padded with tools nobody uses, or optimized for teams of fifty.

This is not that list. This is a small, opinionated collection of solo developer productivity tools that solve real problems for indie developers working on side projects. Every tool here earns its spot by reducing friction at a specific stage of the build process. Think of it less as a generic roundup and more as an indie developer workflow guide.

The stages that matter when you are building alone: planning, building, deploying, and resuming.

Planning

When you are solo, planning does not mean Jira boards and sprint ceremonies. It means having just enough structure to know what you are building and what “done” looks like.

GitHub Issues (or a plain text file)

You do not need a project management tool. GitHub Issues does everything a solo developer needs: track bugs, capture feature ideas, and mark things as done. If your project is not on GitHub, a TODO.md file in the root of your repo works just as well.

The key is keeping it simple. A flat list of tasks beats a Kanban board when you are the only person moving the cards. The overhead of managing the board starts to exceed the value it provides.

Excalidraw

For the moments when you need to think visually, like sketching a data model, mapping a user flow, or working out how two services talk to each other, Excalidraw is the fastest path from “I need to draw something” to “I have a diagram.” It runs in the browser, feels like a whiteboard, and exports to PNG when you need to save it.

No account required. No learning curve. That matters when your session budget is 45 minutes.

Building

This is where most tool lists spend all their time. I will keep it short because the best tools for building are the ones you already know. Switching your editor or framework mid-project is a form of procrastination.

Your existing editor, configured well

VS Code, Neovim, Zed, whatever you use. The tool matters less than the configuration. Spend an hour setting up your keybindings, snippets, and extensions for the kind of project you are building. Then stop tweaking and start coding.

One specific tip: set up a project-specific workspace configuration with the right linter rules, formatters, and test commands. The less you have to think about tooling during a session, the more of your limited energy goes toward the actual code.

Claude Code (or your preferred AI assistant)

AI coding assistants have changed the math on solo development. Tasks that used to eat an entire evening, like writing boilerplate, generating test cases, debugging a weird error, or scaffolding a new module, can now happen in minutes.

This is not about replacing the thinking. It is about compressing the mechanical work so your short sessions go further. When you only have an hour, spending 40 minutes on boilerplate is a problem. Spending 5 minutes and moving on to the interesting part is a different experience entirely.

SQLite (for most things)

If your project needs a database, start with SQLite. No server to run. No connection strings to configure. No Docker containers to manage. Just a file.

For a solo project, SQLite handles more than most developers expect. It is fast, reliable, and eliminates an entire category of “it works on my machine” problems. You can always migrate to Postgres later if you need to. You almost certainly will not need to.

Deploying

Deployment used to be a whole project in itself. For solo developers in 2026, it should take less than an hour to go from “it works locally” to “it is live on the internet.”

Vercel / Netlify / Cloudflare Pages

For frontend projects and full-stack frameworks (Next.js, Astro, Nuxt, SvelteKit), these platforms handle deployment with almost zero configuration. Push to main, get a live URL. That is the entire workflow.

Pick whichever one fits your framework. They are all good enough. The important thing is that deployment is not a bottleneck. If shipping requires a 45-minute DevOps session, you will avoid shipping. If it requires a git push, you will ship constantly.

Fly.io / Railway

For backend services, containers, or anything that needs a real server, Fly.io and Railway offer the closest thing to “Vercel for backends.” Reasonable free tiers, simple CLIs, and fast deploys.

The pattern is the same: remove friction from the deployment step so it does not become a reason to delay shipping. Scope your project small, deploy early, iterate in public.

Resuming

This is the stage that almost every tool list ignores. And for solo developers, it might be the most important one.

Building alone means you are the only person who holds the context. There is no teammate to ask, no Slack thread to search, no standup notes to review. When you step away, the context leaves with you.

We wrote about this in detail in our posts on why side projects die and context debt. The short version: the cost to resume a project after a break is the thing that actually kills most side projects. Not the building. The coming back.

KeepGoing

This is our tool, so take the recommendation with the appropriate grain of salt. But we built KeepGoing specifically because nothing else in the solo developer toolkit addresses the resuming problem.

It works like this: at the end of a coding session, KeepGoing prompts you to capture where you left off. Not a task list. A context snapshot: what you were doing, what is half-finished, what the next step is. The next time you open the project, that snapshot is waiting for you.

The goal is to reduce the cold-boot cost to near zero so that your 45-minute evening sessions start with coding instead of archaeology. It also integrates with Claude Code and GitHub Copilot via MCP, so your AI assistant knows what you were working on when you come back.

Good commit messages

This is not a tool. It is a habit. But it belongs here because your commit history is the most persistent record of your project’s evolution, and most solo developers write terrible commit messages because nobody else is reading them.

Future you is reading them. And when you are trying to figure out why the auth flow changed three weeks ago, "fix stuff" is useless. "move token refresh to middleware to fix race condition on concurrent requests" tells you exactly what happened and why.

Write commits for the version of you that has zero context. That person shows up more often than you think.

The meta-point

The best toolkit for solo developers is not the one with the most tools. It is the one with the least friction at every stage.

Every tool on this list earns its spot by making one specific part of the process cheaper: cheaper to plan, cheaper to build, cheaper to deploy, cheaper to resume. These are tools to help finish side projects, not just start them. The goal is a workflow where the gap between “I have 45 minutes” and “I am making progress” is as small as possible.

How to finish a side project is not about working harder. It is about removing the things that slow you down.

---

The right tools do not make you more productive. They make it harder to stop.