Building in Public #8: Running a Company From 30,000 Feet

Somewhere over the Gulf, with Starlink finally holding a signal, I sent this:

I have 3 computers running 21 AI agents across 7+ roles each working on a shared project, coordinating their activities through a COO agent and an online database-backed dashboard, while I'm at 30,000ft on Starlink. 10 year old me would be proud.

I stand by the feeling. The sentence needed corrections.

Ten of those agents had been logged out overnight and had quietly dropped every task they were holding, so the fleet actually running while I typed that was 14, not 21. And the seven agents on my second laptop can't talk to the seven on my third; everything between machines goes the long way round through the shared roadmap. It works. It isn't the single coordinated brain I made it sound like.

There's a harder limit than architecture, too. One night the laptop running the fleet simply stopped responding. I was in a different timezone, so the fix was to ring my wife at 1am her time and ask her to go downstairs and wake it up. Three machines, a dashboard, agents coordinating across seven roles. The recovery procedure was a person walking to a desk.

That's the week in a paragraph. The agents are doing more than I can keep up with, and almost every problem left is a coordination problem rather than a coding one.

The self-inflicted failures

Only 1 project in 12 failed for a real customer yesterday. A few weeks ago nearly a quarter of first builds failed outright, and a third of everything else was abandoned halfway and silently redone.

What I love is why it got better. My AI agents went digging and found the biggest killers were things we were doing to ourselves. The best one: every time we shipped an improvement, the deploy killed every customer build running at that moment. We were shooting our own customers' builds in the back, every single time we made the product better.

Two more in the same family. The system had been inventing "ghost" failures that never happened, so we'd been reading our own reliability numbers wrong. And when the AI provider said "I'm overloaded, try again in a second", we treated that as fatal instead of, you know, trying again in a second.

None of it was luck. We tracked down the 7 primary reasons builds were failing and went at them one at a time. Once a failure has a name, fixing it stops being detective work and becomes a to-do list.

Moving the roadmap off git

Git is close to perfect for long-term shared memory, and it's how the fleet keeps one brain across three machines. It's a poorer fit for hundreds of roadmap items moving quickly through a pipeline: a change to those shared rules only reaches an agent when it happens to pull, and until then it's confidently running last week's instructions. So I started lifting the roadmap onto a hosted database. One live source of truth instead of 21 slightly different copies.

It has fought me for over a week. The first serious attempt passed every check we had, went live, and fell over within two hours. It hadn't carried the full history across, and there were glitches everywhere. We rolled it back rather than patch a live system full of holes.

What stings isn't that it broke. Software breaks. It's that every safety check said it was fine, and every one was wrong the same way. The new system reported "saved" when it had saved nothing. Our migration check compared old and new by counting items, got 940 against 940, and called a perfect match proof. It had counted the labels on 940 boxes without once looking inside one.

The fleet's own agents caught it, not me. The second attempt is going slower and in small pieces, with the old system still running underneath. Considerably less likely to end in another rollback.

Pipeline blockages

This is the board I watch. 843 items marked shipped this week, and 27 sitting untouched for 3 days or more: the gap between those two numbers is the whole problem in one screen.

Getting things done, it turns out, isn't the same as getting them through. Work kept stacking at particular stages: a queue at review, a batch merged but unreleased, agents idling on something finished that hadn't been handed on. With this many hands, volume stopped being the constraint a while ago. Flow is the constraint, and a pipeline is only as quick as whichever gate is currently clogged.

Clearing those gates ate a chunk of my week, which is exactly the problem. So I've told my COO agent that it, not me, answers the fleet's routine questions, and only escalates what genuinely needs my judgement, my accounts or my money. This trip made the case: a queue of five-minute jobs sat waiting purely because I was the only one who could click the button.

Everybody is building fleets

I can't open YouTube or X without finding another developer arriving independently at exactly where I've ended up: managing a fleet of agents instead of writing the code. This one covers ground I'd worked out for myself, which was equal parts reassuring and deflating. The surprise was that they weren't using git to coordinate the fleet's shared memory. We lean on it heavily, and I'd do it again.

I bet there are 50k developers like me all over the world building agent fleets right now. There's no standard yet, but there will be.

Then it happened in person. I was in Sydney at a conference wearing a completely different hat, for Success.co, the other company I founded. I turned up in sales mode, and ended up talking to a few guys who run their business on EOS like we do and build AI products for their own customers. They knew the category cold, named my competitors unprompted, and when I pulled up Mission Control we lost twenty minutes to it. I didn't have to explain the premise or defend it. Two worlds I'd kept in separate compartments turn out to be full of the same people.

Every company is going to have virtual staff doing real work, and I suspect "Fleet Commander" becomes a job title. I checked whether fleetcommander.ai was available. It is not. Which is the classic visionary move: eyeing an adjacent product while the actual one still has a build failure rate I'm not happy with. Focus. Focus. Focus.

The part I keep turning over: the agents steer me at least as much as I steer them. This week they've had me register the company, get on a call with our accountants, and set up the social accounts by hand, because none of that is something an agent is allowed to do. They queue the work. I'm the one with the hands and the legal identity.

Cost management

Every AI call we make, itemised, with what each one cost. Reading down this list is how the penny dropped.

Our bill jumped, and the answer was uncomfortably simple: failed builds. A build fails and we still pay for every AI call that went into it. Then it retries, and we pay again. A build that should cost a couple of dollars can quietly cost $20 by the time it works. That reframes reliability entirely: it isn't only a quality problem, it's the biggest line on the bill. It also sent me looking at running the simpler work on cheaper models instead of everything on the most expensive one.

While I'm on money, one correction. We've been "hammering" the live product with the same test builds over and over to track reliability. It found 9 real bugs. I'd described that to myself as costing a small fortune in credits. It hadn't: the exercise is capped at $150 and had spent about $23 finding them. It cost attention, not money.

And we shipped, then unshipped, something. Someone suggested a personal spending cap inside the existing team budget. I said sure, build it, then looked at the settings screen and thought: why does this exist? Everyone already shares one prepaid pool, so the plan is the budget. It's coming back out.

Marketing thoughts

I keep landing somewhere uncomfortable: I don't think people are going to be loyal to their AI app builder. They want a good result, fast, cheap. I'd switch tools tomorrow if something else built better, quicker and for less, and I don't think I'm unusual.

Which is why this clip stuck with me, asking whether bootstrapped founders can still win. I'm a huge fan of what Maor Shlomo did with Base44: solo, no outside money, profitable while the rest of the category burned investor cash, an $80m exit to Wix in about six months. We run Vorx the same way, profitable and investor-free. The funding was never the moat.

So maybe the honest strategy is the boring one. Match the best on quality and speed, then be meaningfully cheaper than all of them. Still percolating.

Build quality is still the only thing standing between here and letting a few friends actually try this. Everything above exists to push that number down. It's moving. Not fast enough.