Every developer I know has the same folder problem. It starts as ~/Projects, then it grows, then it becomes a graveyard. You have a half-finished Next.js app from March, a React Native experiment, a Python scraper, three monorepos you are sure you will get back to.

Here is the uncomfortable truth about organizing side projects: the problem is rarely a lack of organization systems — it’s that the system becomes more work than the projects themselves. Most productivity advice for side projects assumes you’ll open a kanban board, fill in a template, and update a status column. Few of us actually do that. We just want to open the damn project and get back to where we left off.

This guide is a system built around that reality. It keeps overhead near zero, works with the tools you already use, and is designed for the way developers actually work in 2026.

1. Start with a folder structure you can scale (and forget)

Before any tool, get your directories right. A good structure means you never have to think about where a project lives.

A minimal, proven layout:

~/Projects/
  active/        # things you ship and maintain
  learning/      # tutorials, experiments, "just trying it"
  archive/       # done, abandoned, or on ice

Why these three and no more:

  • active/ — the small set you actually touch. Treat it like a queue, not a collection.
  • learning/ — a guilt-free space for experiments. This is where most “vibe coding” projects belong.
  • archive/ — the key to peace of mind. Abandoned projects don’t get deleted, they get archived. Archive is not failure; it’s a decision you made with full information.

I wrote more about the mindset shift in why too many side projects burn developers out. The short version: your graveyard of Downloads-folder projects isn’t a discipline problem, it’s a lack of a closed loop.

2. Give every project two small inputs, not a full template

You do not need a Notion database with tags, links, priority, and a roadmap. You need to answer two questions every time you return to a project:

  1. Where do I hook back in? — the single command to run it.
  2. What was I doing? — one or two lines of next steps.

A README.md per project, with just those two sections, is 90% of the value of any project tracker:

# project-name

## run
npm run dev

## next
- finish auth flow
- fix the fetch error in components/Data.tsx

If you open a project a month later, this file tells you everything. No login, no board, no status fields.

This is where most “organize side projects” guides stop, and it’s exactly where developers’ problems really begin. The bottleneck isn’t knowing your folder structure — it’s the cost of switching between projects.

Think about a typical flow today:

  1. Find the project (search Finder or cd into folders).
  2. Guess which editor to open.
  3. Open a terminal.
  4. Remember the run command.
  5. Manually type npm run dev (or python main.py, or cargo run).

That’s five steps, every time, multiplied by half a dozen projects. No wonder people drift back to whatever was already open.

A project launcher collapses this into one click. Dev WorkDir is a macOS menu-bar and desktop project launcher built exactly for this: it scans your project folders, detects the framework, remembers your editors and terminals, and double-clicking a project card opens it and runs the right command automatically.

Double-click "my-next-app"  →  VS Code opens + `npm run dev` starts in Terminal

For developers juggling side projects, this single change removes more friction than any organizational template. You can see all your active/ projects in the menu bar and switch in one click — no navigation, no terminal typing.

4. Use project-level todos, not a global task manager

Project management apps assume you live inside them. Developers don’t — they live in their editor. So the todo list that actually sticks is the one that lives with the project.

Keep a small per-project todo list next to the project card. When an idea hits you mid-sprint, jot it on the project it belongs to and keep going. This is how you stop scattering ideas across iOS notes, Discord DMs, and random files.

A global view of “today’s todos across all projects” is a nice bonus — but only if it doesn’t require you to update a board manually. In Dev WorkDir, todos are attached to each project automatically and aggregated into a Watchtower view, so nothing is lost without any extra data entry on your part.

5. Automate the running, not the remembering

The real win in 2026 is not remembering your commands — it’s not having to. Have your launcher store the run script so you never type it again.

Common run patterns Dev WorkDir auto-detects:

Project type Auto-run command
Next.js / Vite / React npm run dev
Python python main.py
Rust cargo run
Docker docker compose up

Configure it once per project, and every future open is one double-click. Your brain stops being taxed with “how do I run this one again?”

6. Run a monthly 10-minute archive sweep

The system stays clean if once a month you spend ten minutes moving anything you haven’t touched to archive/. Set a calendar reminder. That’s it.

Ten minutes of upkeep beats any tool that requires daily attention, because a system you actually use is better than a perfect system you ignore.

The 30-second summary

  1. Three folders: active/, learning/, archive/.
  2. A tiny README.md per project with run and next.
  3. Use a macOS project launcher so switching is one click.
  4. Keep todos attached to the project, not a separate app.
  5. Let the launcher auto-run your scripts.
  6. Archive once a month, in ten minutes.

Organization is not about discipline — it’s about removing friction. The fewer steps between you and “I’m coding,” the more projects you actually finish.

Built this workflow? Dev WorkDir makes step 3–5 automatic on macOS. See how it works.