Skip to content

How to Manage Multiple AI-Coded Projects Without Losing Track

The Problem

I lost track of my own apps. Again.

I was trying to remember which hosting platform I used for my recipe app. Was it Vercel? Netlify? Railway? And what about the domain renewal date? Did I use Supabase or PlanetScale for the database?

Then I found a Reddit post that hit home. Someone had built six live apps with Claude:

  • hitormiss.co
  • floid.design
  • bentu.co
  • spork.website
  • plainsight.cc
  • thisisnotanapp.com

They said: “it is a lot to track…maybe new app idea…”

That’s when it clicked. The person who built these apps was drowning in the same problem I had. Too many projects. Too many services. Too many domains. No system to track them.

The irony? We use Claude to build apps. Why not use Claude to manage them too?

What Gets Lost When You Build Fast

When you code with AI, you ship fast. Ideas become prototypes in hours. Prototypes become live apps in days.

But speed has a cost. You accumulate:

AssetTracking Issue
GitHub repositoriesWhich account? Public or private?
Hosting platformsVercel, Netlify, Railway, Render, Fly.io?
DomainsWhere did you buy them? When do they renew?
Backend servicesSupabase, Firebase, PlanetScale, Upstash?
API keysWhich project uses which key?
Project statusActive? Abandoned? Prototype? Production?

I had projects I forgot existed. Domains I paid for but never used. Backend services running somewhere, billing me monthly, while the frontend had been deleted months ago.

The Solution: A Tracking System

I created a simple PROJECTS.md file in a central repository. Nothing fancy. Just a table.

PROJECTS.md Template
# Project Tracker
| Project | Repo | Hosting | Domain | Backend | Status | Last Session |
|---------|------|---------|--------|---------|--------|--------------|
| myapp | github.com/me/myapp | Vercel | myapp.com | Supabase | Active | 2026-03-15 |
| recipetracker | github.com/me/recipetracker | Netlify | - | PlanetScale | Prototype | 2026-02-20 |
| habitlog | github.com/me/habitlog | Railway | habitlog.dev | Firebase | Abandoned | 2026-01-10 |
## Domain Renewals
| Domain | Registrar | Renewal Date | Cost | Auto-Renew |
|--------|-----------|--------------|------|------------|
| myapp.com | Namecheap | 2026-06-15 | $12 | Yes |
| habitlog.dev | Porkbun | 2026-04-01 | $15 | No |
## Backend Costs
| Service | Project | Monthly Cost | Billing Date |
|---------|---------|--------------|--------------|
| Supabase | myapp | $0 (free tier) | - |
| PlanetScale | recipetracker | $0 (free tier) | - |

This lives in a repo called project-tracker. I update it whenever I start a new project, deploy something, or change services.

Why This Works

The tracking file solves three specific problems:

1. Context Switching Costs

When I return to a project after weeks away, I need to remember where everything lives. The tracking file tells me the repo URL, the hosting platform, and whether I have a backend running somewhere.

2. Surprise Bills

I once got a $50 charge from a service I forgot I was using. Now I track every backend service and its cost tier. Free tier projects get flagged for deletion if inactive.

3. Domain Management

Domains auto-renew by default. But do you still need them? I review my domain list monthly. If a project is abandoned, I cancel the renewal and let it expire.

The Per-Project CLAUDE.md Pattern

Each project gets its own CLAUDE.md file. This file tells Claude how to work with that specific project.

CLAUDE.md Example for a Next.js Project
# Recipe Tracker
## Architecture
- Frontend: Next.js 14 with App Router
- Backend: Supabase (PostgreSQL + Auth)
- Hosting: Vercel
- Domain: recipetracker.app
## Key Files
- `/app/page.tsx` - Main entry point
- `/lib/supabase.ts` - Database client
- `/components/RecipeList.tsx` - Core component
## Current Status
- Authentication works
- Recipe CRUD works
- Need to add: image upload, sharing features
## Known Issues
- Build fails if environment variables missing
- TypeScript errors in `/app/api/` routes (ignored for now)
## How to Run
1. `npm install`
2. Copy `.env.example` to `.env.local`
3. Add Supabase credentials
4. `npm run dev`

When I open a project in Claude Code, I don’t need to remember how it works. The CLAUDE.md file provides immediate context.

What Happens Without This System

Let me show you a real example. Before I started tracking:

I had a project called expense-splitter. Built it in a weekend. Deployed to… I couldn’t remember. Checked Vercel - not there. Checked Netlify - not there. Checked Railway - found it.

The database was hosted on PlanetScale. I was paying $10/month for a hobby project I hadn’t touched in four months.

Total wasted: $40. Not life-changing. But multiplied across multiple projects? It adds up.

A Better Workflow

Here’s how I work now:

New Project Setup Flow
1. Create new Claude session
2. Claude generates initial code
3. Create GitHub repository
4. Add CLAUDE.md file to repo
5. Update PROJECTS.md with new entry
6. Deploy to hosting platform
7. Update PROJECTS.md with hosting details
8. If domain purchased: add to Domain Renewals section

Every new project gets tracked before deployment. Not after.

The Meta-Project Approach

The Reddit poster said: “maybe new app idea” when drowning in project management. Why not build exactly that?

I asked Claude to create a project dashboard:

Meta-Project Prompt
Create a simple HTML file that displays my projects from a JSON file.
For each project, show:
- Name (link to live site)
- GitHub repo (link)
- Hosting platform
- Status (Active/Prototype/Abandoned)
- Last updated date
- A health check button that pings the site
Include a form to add new projects.
Use localStorage for persistence.

Claude generated a single HTML file. 200 lines. Works offline. No backend needed.

I bookmarked it as my “project dashboard.” Now I have one place to see all my apps, their status, and links to everything.

Monthly Review Process

I added a recurring task to review my PROJECTS.md file:

First of every month:

  1. Open each active project in browser - does it still work?
  2. Check domain renewal dates - any expiring this month?
  3. Review backend costs - any services to cancel?
  4. Update “Last Session” dates for projects I worked on
  5. Mark abandoned projects as “Abandoned” and schedule cleanup

The review takes 15 minutes. It prevents months of forgotten subscription fees.

Common Tracking Mistakes

I made these mistakes so you don’t have to:

Mistake 1: Tracking in multiple places

I used to keep domains in a spreadsheet, repos in a Notion database, and hosting in my browser bookmarks. Everything lived somewhere different. Now everything lives in one file.

Mistake 2: Not recording decisions

I deployed to Railway because it had a free tier. Six months later, I forgot why I chose it. Now I add a “Notes” column to capture reasoning:

| Project | Hosting | Notes |
|---------|---------|-------|
| myapp | Railway | Chose for free tier, easy Postgres |
| recipetracker | Netlify | Simple static site, free tier |

Mistake 3: Ignoring abandoned projects

I felt bad deleting projects I worked on. But keeping them around means:

  • Old repos cluttering your GitHub
  • Services running somewhere
  • Domains auto-renewing

Now I have a cleanup process:

  1. Export any useful code patterns
  2. Delete the repository
  3. Cancel all services
  4. Let domains expire or delete them
  5. Update PROJECTS.md to mark as “Deleted”

Cost Transparency

After tracking for three months, I realized:

ServiceMonthly CostProjects
Vercel$0 (free tier)4
Netlify$0 (free tier)2
Railway$0 (free tier)1
Supabase$0 (free tier)3
Domains$4/month average6
Total$4/month6 active projects

The free tiers are generous for hobby projects. The only real cost is domains.

What Claude Can Read

The best part about using a markdown file? Claude can read it.

When I start a new Claude session for an existing project, I can say:

Read PROJECTS.md and tell me which backend service myapp uses

Or:

Check my PROJECTS.md file. Which domains renew in the next 30 days?

The tracking system becomes queryable. I don’t need to open the file and search. I just ask.

Scaling Beyond One Person

What if you’re working with a team?

The PROJECTS.md approach works, but you might want something more structured:

Option 1: Notion database

Same information, but in a database with views. Filter by status, sort by last updated, assign to team members.

Option 2: GitHub Projects

Create a project board where each project is a card. Add labels for hosting platform, status, and domain.

Option 3: Linear or Jira

If you’re already using project management tools, add projects as epics and track them there.

For solo builders or small teams, a markdown file is enough. The goal is having one source of truth, not building a complex system.

The Real Benefit

After six months of tracking, the benefit isn’t the file itself. It’s the awareness.

I know exactly what I’ve built. I know what’s running. I know what’s costing money. I know where to find everything.

The Reddit poster built six apps. I’ve built more than that. The difference between drowning in projects and managing them is a 50-line markdown file.

When you build fast with AI, you create artifacts quickly. The challenge shifts from building to remembering. A tracking system solves the remembering problem.

Summary

In this post, I showed how to manage multiple AI-coded projects with a simple tracking system. The key point is a PROJECTS.md file prevents losing track of your apps.

The system tracks:

  • Project names and repositories
  • Hosting platforms and domains
  • Backend services and their costs
  • Project status and last active dates

You can query this file with Claude. You can build a meta-project that displays it. But the core insight is simple: when you build fast, you need to track deliberately.

One file. One source of truth. No more forgotten projects.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments