From Project Management to Solo Development
For most of my career, I was a project manager. I helped teams organize work, manage scope, and get software shipped.
Now I am doing something different: building software largely on my own, with AI agents as part of the workflow.
People sometimes describe this as vibe coding. Sometimes that is fair. A prompt can produce a prototype with surprising speed. But the more interesting story is not the prompt. It is everything required to make solo development actually work over time.
The Real Work Behind the Code
The code matters, but so do the systems around the code: issue tracking, notes, memory, credentials, repos, domains, deploy workflows, experiments, and internal tooling.
When one person is building multiple products and prototypes, context becomes fragile. You are not only switching between tasks. You are switching between whole operating modes:
- product work
- infrastructure work
- planning
- deployment
- writing
- debugging
- remembering what exists
- deciding what deserves attention now
That switching cost is not abstract. It consumes real time.
The Hidden Tax of Solo Building
A lot of modern discussion about AI-assisted development focuses on speed. How fast can you get from idea to demo? How quickly can you turn a prompt into an interface?
That is only half the picture.
The other half is what happens after the demo: Can you find it again? Can you deploy it? Can you maintain it? Can you connect it to the rest of your work? Can you stop it from becoming one more disconnected artifact?
In practice, I often spend more time on GitHub, Cloudflare, Vercel, auth, DNS, build settings, credentials, and configuration drift than on the feature that started the task.
That is not a distraction from the work. It is part of the work.
Building the Operating Layer
To deal with that, I have been building a one-person operating system.
Some of it is public: products, prototypes, landing pages, and experiments.
Some of it is internal: Nimbalyst, issue tracking, memory systems, workflow tooling, MCP-based integrations, and CLI-assisted agent workflows.
The purpose is not to build internal tools for their own sake. The purpose is to reduce context switching and preserve continuity.
I do not want to keep acting as a human API between tools.
What Is Getting Easier
MCP and CLI workflows are starting to change the shape of the work. Tasks that recently required a lot of manual copy and paste in PowerShell can increasingly be handled through more continuous agent-assisted workflows.
That does not eliminate judgment. It does not remove testing or decisions. But it does reduce the amount of repetitive orchestration needed to move work forward.
That matters more than novelty.
The Tradeoff
There is a cost.
Every internal system can become its own source of maintenance. Every layer meant to reduce friction can create new complexity. The machinery around the work can start competing with the work itself.
I feel that tension often.
The challenge is not simply to build more tools. It is to build just enough system that product work becomes easier and more continuous, without drowning in your own infrastructure.
What This Site Represents
This site shows some of the public output. Behind it is a larger experiment: what it looks like for one experienced operator, working with AI, to build not just apps, but a working environment for building apps.
The stack will change. The tools will change. Some experiments will hold up; others will be demoted. But the direction is clear.
I am not trying to build everything. I am trying to build a better way to build.