For most of my career, the gap between an idea and a working product was an engineering team. I’m a product manager. I think in milestones, user stories, and outcomes, not in pull requests. I’ve always coded and I can prototype, but turning a loose idea into something that actually runs, and keeps running, was someone else’s job.
That gap mostly closed this year. Two tools did it: Claude Code and Claude Cowork.
Running a Project Like a Team of One
Last week I got the idea to build my own web dashboard for the bird call data I collect. Solo projects like this usually die in a half-finished Docker Compose file, because the boring middle, the part between “cool idea” and “it actually works,” is where momentum goes to die.
Claude Code changed the shape of that work. I wired it up with Gitea and the Gitea MCP server so I could run the project the way I’d run any product: milestones, issues, user stories. I describe the outcome I want. It writes the code, opens the issue, makes the commit. I review the way a PM reviews a team’s work, not the way an engineer stares at a blank file. The middle stopped being the place things die.
It works two ways in practice. Sometimes I open Claude Code with something I want to fix and knock it out right then. Other times I just explain the problem and have it create an issue I can come back to later.
What This Looks Like Day to Day
The pattern repeats across my homelab. The four-camera bird pipeline feeding BirdNET into TimescaleDB. The Frigate camera reviews running through n8n and Ollama. Swapping InfluxDB for TimescaleDB. The news feed I built to quit doom scrolling. Every one of those used to be a weekend idea I might not finish. Now I scope it, hand off the implementation, and stay in the role I’m actually good at: deciding what should exist and whether it’s any good.
Cowork is the other half. It is where the work around the work happens. It reads my blog through the WordPress MCP connector, helps me draft posts in my own voice using a skill I built for exactly that. This post started there. I’m still the editor. I’m just not starting from a blank page.
What Actually Changed
The honest version: these tools did not make me an engineer. They made the engineer optional for the kind of building I do. I have joked a few times, “I pay $100 a month to have an on-call senior engineer to build whatever I want.”
What changed is where my time goes. Less of it goes to syntax I half remember and a pile of browser tabs. More of it goes to the parts a PM is supposed to own: what is worth building, what good looks like, and whether the thing solves the actual problem. That was always the job. For the first time, I can run the whole loop myself.
It still makes me chuckle that now I just tell the agent “Ship it!” and it knows to draft an issue recapping what we did, commit the changes, and push them to my repo server in one go.
