One Founder, Eight Agents: The 12-Step Roadmap to Running a Tech Company from Mission Control

Grok Bot as Mission Control. Claude Code, Codex and Cursor as the engineering team.

I’m a solo founder. In the last 7 days, 289 pull requests merged into my codebase. AI agents wrote every one of them.

I’m not a 10x engineer, and I don’t have a team. I started using Claude Code hands-on around August 11. Since early October I haven’t driven the agents myself. I talk to one assistant, Grok Bot, which I call Mission Control. It turns what I ask for into work, hands that work to Claude Code, Codex and Cursor cloud agents, and only comes back to me when a decision is actually mine.

The repo as of today: 2,320 commits, 1,660 PRs opened, 1,173 merged.

I’m applying to YC with what this built. Below is the exact setup, step by step, so you can copy it.

Step 1: Pick one assistant to be Mission Control

Don’t talk to five coding tools. Talk to one.

Mission Control is the only thing I talk to. I say “the chat screens feel cluttered, research better ones,” and it figures out which repo, which agent and which order. It holds the rules, the memory of past decisions, and the state of every job.

The coding agents are workers. Mission Control is the manager. If you skip this step, you become the manager, and you’re back to writing tickets all day.

Step 2: Turn every ask into a queue item

An ask in chat goes away once you scroll past it. A queue item stays put.

Each request becomes a written item in a queue file: what to do, where, what “done” means, and what’s off-limits. Agents pull from the queue. Mission Control writes to it.

A real-shaped example:

ID: CHAT-SCREEN-04
Surface: business dashboard / assistant chat
Depends on: CHAT-KIT-A (merged)
Do: Replace the old chat view with the shared chat kit.
    Character stays at the top. Keep every existing feature.
Done when: builds, tests pass, screenshot attached to the PR
Limits: draft PR only. No new dependencies. No layout changes
        beyond the approved mockup.
Status: ready

The “Depends on” line matters. It lets work wait for other work without me tracking it.

Step 3: Run agents in parallel lanes

A lane is one agent with its own clone of the repo and its own branch. I run up to 8 at once across Claude Code, Codex and Cursor cloud agents.

Separate clones mean agents never step on each other’s files. Separate branches mean every change shows up as its own pull request I can read, hold or throw away.

Mix tools on purpose. Different agents are good at different things, and if one is rate-limited or stuck, the others keep going.

Step 4: Write the rules before the prompts

The rules matter more than the prompts. A clever prompt helps one task. A rule protects every task.

Here’s my list, close to word for word:

HARD LIMITS (every agent, every lane)
- Never touch production.
- No live payments. Stripe stays in test mode.
- Never merge to main on your own.
- Never delete anything without my yes.
- No secrets in chat. Ever.
- Open draft PRs only.
- No UI change to an approved layout without a mockup and my approval.
- Small, reversible polish on a dev branch is pre-authorized.

The last line is what keeps it moving. If every small change needs my approval, I become the bottleneck again. So I pre-approve a category of small, reversible work, and I keep the big calls for myself.

Step 5: Draft PRs only

Agents never ship. They propose.

Every change lands as a draft pull request. That gives me a diff, a description and a place to say no. It also means a bad idea costs me one closed PR, not a broken app.

Step 6: Automate merging, locally

Once a PR is approved, a local merge driver takes over. It rebases each PR onto the latest main, runs the checks, and merges only if they pass. If two PRs conflict, it holds one and sends it back to a lane to fix.

I don’t use GitHub Actions for this. The checks run on the same machine the agents use. There’s no CI bill.

This is the step people skip, and it’s why their agent setups stall. Agents can write code faster than a human can review and merge it. If merging is manual, you’ve just moved the bottleneck.

Step 7: Protect the machine

Eight agents building at once will eat a computer. I learned that the hard way when builds started failing because the disk ran out of room for new files.

So there’s a lane guard. If RAM goes above 90%, it pauses lanes. When memory drops back down, they resume. Mission Control also watches disk use and asks me before it deletes anything to make room.

It isn’t exciting, but without it the setup falls over in the middle of the night.

Step 8: Schedule routines so it runs while you’re away

An hourly check routine does three things:

Refills any lane whose queue is empty.
Kills jobs that are stuck.
Pings me only when a decision is actually mine.

Rule 3 is the important one. Most status updates are noise. I want to hear “this needs your call,” not “lane 4 is still running.”

Last night a shared chat UI kit merged at 2:06 AM ET. Nine screens were queued behind it with “Depends on: CHAT-KIT-A.” The agents started on all nine right away. I didn’t touch it.

Step 9: Add a nightly bug sweep

Every night an agent walks the codebase looking for bugs and opens fix PRs. Same rules: draft only, no production, nothing deleted.

I wake up to a short list of fixes to approve instead of a list of bugs to find.

Step 10: Give each product surface an owner bot

My product has five surfaces: a tourist app, a locals app, a business dashboard, city partner dashboards, and a master admin console.

Each one has a side-owner bot. Its job is to know that surface well, notice what’s missing or broken, and propose improvements. I approve or reject. Approved ideas go into the queue like everything else.

This is the part that feels most like running a company rather than a codebase. I’m not deciding every feature. I’m reviewing proposals from owners.

Step 11: Put design behind an approval gate

Agents will happily ship ugly UI. So design gets its own process.

Design bots research real references on Mobbin, the screen library, then show me mockups before any code gets written. I’ve rejected a heat map because it looked bad. I’ve approved a chat redesign after seeing the mockups first. The rule: no UI change ships without my approval, and small polish is pre-authorized.

Taste is the one thing I can’t delegate, so I put it at a single checkpoint instead of spreading it across every PR.

Step 12: Scale by adding lanes, not hours

When something matters, I don’t work later. I ask Mission Control to open more lanes.

But more lanes only help when the work can run side by side. If everything is waiting on one merge, ten agents won’t make it faster. Mission Control tells me which case I’m in, splits the work so the next batch runs in parallel, and sets a watcher to start it the moment the blocker clears.

What it’s built so far

The company is Cities In My Pocket: one app for visitors and locals in every city, plus dashboards that give local businesses and cities real data.

Running this way, it has produced:

A tourist app
A locals app
A business dashboard
Two city data dashboards: DMO IQ for visitor data and CityIQ for local data
An admin console

The city data is privacy-safe by design. Any group under 3 people is hidden, so nothing can single anyone out.

The repo: 2,320 commits. 1,660 PRs opened. 1,173 merged. 289 merged in the last 7 days.

My job now

I don’t write code anymore. I make calls.

What to build. What it should look like. What’s off-limits. Which proposal goes in and which one doesn’t. I approve a mockup, I reject a heat map, I say “never cut a page.” The agents do the rest.

Where this goes

Code isn’t the bottleneck anymore. Taste and decisions are.

For a long time the size of a company tracked the size of its engineering team. That’s breaking. One person with a clear set of rules, a Mission Control assistant, and a few coding agents in parallel lanes can ship like a much bigger team, as long as they can say exactly what they want and what they won’t allow.

I think this is how tech companies will be built and run: a founder who decides, an assistant that coordinates, and agents that build. The founders who win won’t be the ones who write the most code. They’ll be the ones who make the best calls quickly.

That’s what I’m taking to YC.