How I Build as a One-Person Studio
I'm a one-person engineering and science studio. To get the work of a team out of a single person, I run several specialized AI agents in parallel, each focused on a different part of a project at the same time.
This isn't a thought experiment. It's how I build software day to day, including Zentrr, my own product.
What changes in practice: work that I used to do strictly one stage at a time can overlap, so a project moves in days where it used to move in weeks.
The Problem with Linear Development
Building software solo tends to follow a linear path:
- Gather requirements
- Design the architecture
- Build the backend
- Create the frontend
- Write tests
- Handle DevOps
- Document everything
Each step waits for the previous one. As one person, you can only be in one of those stages at a time, so the calendar stretches out.
Working in Parallel Instead
Here's the shift in how I sequence the work:
Strictly linear:
- Stage 1: Architecture and planning
- Stage 2: Backend development
- Stage 3: Frontend development
- Stage 4: Testing and deployment
- Each stage blocks the next
In parallel:
- Several workstreams run at once, each handled by an agent I'm directing
- I spend my time integrating their output and making the calls only a human should make
The point isn't a guaranteed speedup for everyone — it's that overlapping the stages removes the idle time where one part of a project waits on another.
How the Parallel Approach Works
Instead of working through a project one file and one stage at a time, I direct several specialized agents that each focus on a different part of it. Think of it as drafting several pieces of the work concurrently and then bringing them together.
I tend to scope agents around a specific area:
- Architecture and infrastructure
- Frontend development
- Backend systems
- Security and compliance
- Testing and quality assurance
- DevOps and deployment
Running multiple agents is only half of it. The harder half is the orchestration.
Isolated Environments Keep Them From Colliding
Each agent works in its own isolated environment — typically a separate git worktree — so they don't overwrite each other's changes. That keeps merge conflicts down and lets independent pieces of work proceed without waiting on one another.
An example from my own work: building Zentrr, my multi-tenant agent platform, I'll frequently have several agents in flight at once — one on a new feature, another writing tests, another reviewing a diff — each in its own worktree. The verification and review steps run as their own workstreams rather than as an afterthought at the end.
The Human Part: Orchestrating the Work
Here's the part that's easy to miss: running several AI agents in parallel isn't a matter of launching them and walking away. It takes focus and judgment.
As the person directing the work, I:
- Give each agent precise guidance to keep it on track
- Make the architectural decisions that ripple across every workstream
- Resolve the integration problems between parallel workstreams
- Hold a consistent vision across all the pieces
- Steer agents toward good solutions instead of letting them wander
The honest part: directing parallel work is mentally taxing. It's like conducting an orchestra where each musician is playing a different piece and you have to make it harmonize. The output is only as coherent as the direction.
How I Run a Project This Way
My process looks roughly like this:
- Requirements analysis — understanding not just what's needed, but why
- Planning — deciding what can run in parallel and what genuinely has to be sequential
- Orchestration — directing several workstreams toward one coherent design
- Integration — bringing the parallel work together without conflicts
- Quality control — keeping the standard high across everything
- Iteration — shipping in small, frequent increments
What I've Actually Gotten Out of It
In my own work, the practice has meant:
- Independent pieces of a project no longer wait in line behind each other
- Fewer merge conflicts, because each agent works in an isolated environment
- Testing and security treated as their own workstreams, not a last-minute scramble
- Documentation written alongside the code rather than after it
- More of my own time spent on design and judgment, less on mechanical work
These are my own results from building this way; your mileage will depend on the project and how clearly you can scope the work.
Why It Works for Me
It isn't really about "using AI." For me it comes down to:
- Knowing the system architecture well enough to split a project into independent pieces
- Being able to hold several parallel workstreams in my head at once
- Having a sense, from doing it repeatedly, of when to parallelize and when not to
Parallelizing the wrong things just creates rework. Most of the skill is knowing where the seams are.
A Real Practice, Not a Pitch
This is simply how I work as a solo studio — including on Zentrr, where I dogfood the same approach every day. It won't suit every project, and it doesn't remove the need to understand what's being built. What it does is let one person cover more ground without dropping the bar on quality.
If you want to talk about whether it fits what you're building, get in touch.
P.S. Parts of this post were drafted with the same AI-assisted workflow it describes, then edited by me. That's the point — I write about how I actually work.
