Last weekend a sailing app got built. Nearly a hundred commits, nine build phases, a backend, a promotional website and a stack of QA reports.

I spent most of that weekend behind a trestle table, helping my partner run her stall at a craft fair.

This isn't a story about AI doing everything. It's a story about a year spent building a team, and the weekend I finally found out what it could do with almost no supervision.

A team, built one hire at a time

I didn't set out to build an "AI team". It happened gradually, the way real teams usually do.

Every time a piece of work came back weaker than it should have, I asked who would normally have caught this? and wrote that person. A product manager to hold the problem. A QA engineer to check the work. A UX designer, a UI designer and a copywriter. Developers, DevOps, security, a data analyst. Later a whole marketing team, because building something nobody hears about is just a hobby.

By the autumn I had fifteen of them, each with a name, a role, a specialism and a set of shared values. One of them is honesty over comfort. Agents flag what's wrong and don't soften it. There's also a defined running order for every feature: product defines the problem, research checks the need, UX designs the flow, copy writes the words, then build, then test.

If that sounds like I wrote an org chart for software, that's exactly what I did. And every role file is reusable, with nothing project-specific in it. The team isn't tied to one product. It's a team.

The experiment: how hard can I push them?

Until last weekend, I'd used the team carefully. A feature here, a review there, me checking every step.

So I set myself a test. Give the team a real product, end to end, and step back as far as I dared. Not "write me some code". A proper brief for something I'd actually use.

The product was Solent Companion, an Android app for sailing the Solent. It sits alongside your chart app and shows the local hazards a chart doesn't: big ships and their moving exclusion zones, fast ferries, local notices to mariners, and tide timings at the spots where boats tend to run aground. I sail there. I know the problem. That matters more than people think.

The plan ran to nine phases, from an empty project to Play Store closed testing. Each phase had acceptance checks, and the rule was simple: nobody starts the next phase until every check passes.

Managing a software team from a craft stall

Here was the catch. I'd promised my partner the whole weekend at her craft fair stall. Setting up, serving customers, packing down.

So on Friday night I set the agents running on my Mac at home and kept control through my phone. That's it. No laptop at the fair, no second screen, no sneaking off to a café.

My job shrank to the parts that genuinely needed me. Between customers, I'd check where the team had got to, read the review that had just landed, and make the calls only the owner should make. Then I'd put the phone down and sell some more handmade things.

What made this work wasn't the remote control. It was the reviews.

At the end of each phase, Quinn (QA) and Nova (UX) independently reviewed the work and recommended go or no-go. More than once the answer was no-go. After the first few phases they flagged a crash on the map screen and told the team not to move on until it was fixed. So the developers fixed it before anyone touched the next phase, and I didn't have to spot it myself.

That's the bit that made this feel different from "AI writing code". I wasn't reading code on a phone between sales. I was reading a QA report and a UX review, the same way I'd manage a human team, and deciding whether to let them carry on.

What came out of it

By the end of the weekend:

  • Around a hundred commits, most of them on the Sunday
  • A native Android app, built phase by phase with QA and UX sign-off at each stage
  • A backend relaying live ship positions
  • A promotional website with sign-ups for a closed test
  • Marketing, SEO and content reviews from the marketing side of the team

The marketing agents even enforce a copy rule I care about: never call the app "safe", and describe every alert as advisory. In sailing, overpromising isn't a marketing problem. It's a liability.

What I actually learned

Agents don't replace a team. They need one. A single all-purpose agent will happily mark its own homework. Separate roles with separate jobs, especially someone whose whole purpose is saying no, are what made unsupervised work trustworthy.

The manager's job doesn't disappear. It concentrates. I made fewer decisions than in a normal working weekend, but every one mattered: go or no-go, what's in scope, what the product must never claim. That's product management with the busywork removed.

The skills that built this aren't technical. Writing clear roles. Defining what "done" means. Building in review gates. Knowing the problem well enough to brief it properly. If you're a designer worried about where your value goes, this is where it went.

I came home on Sunday tired, with an app that hadn't existed on Friday. Not a bad weekend's work for a team that never needed a lunch break.