Every founder knows the problem. You can see the product clearly. You have the designs. What you don’t have is a ten-person engineering team, the budget to hire one, or the months it takes to get one working well together.

So we built our own team.

I wrote earlier about why we organized AI development this way, and why proof-of-concept work deserves its own team, in Build the Demo Without Breaking the Roadmap. This is what that team actually shipped.

Their names are Doug, Bob, Chris, Peter, Wayne, Gord, Mike, Steve, Sandy, Sally and Terry. They are AI agents, and they built nearly all of the working demo of CareBee, our app for families who coordinate care for an aging parent.

CareBee is a family caregiver app from AXIMEDIC, a Yom Shore Ventures company — carebeeapp.com. I led years of prior work on the product. This article is about the working demo our AI dev team at CTO Rescues built in nine days.

Here’s how it worked, what surprised us, and what I’d tell any leader thinking about doing the same.

It’s a team, not a chatbot

The usual way to use AI for code is one assistant in one chat window, trying to do everything. That’s like hiring one person to write the spec, build the feature, test it, review it and sign off on security, all before lunch. You get speed, but no checks and balances.

So we organized our AI the way a good engineering org is organized: specialists with clear roles, and nobody marking their own homework.

  • Doug, the foreman, reads every request first. He writes the spec: acceptance criteria, which files are in scope, how big the job is, and who should build it.
  • Mike, the tester, writes the acceptance tests before any code exists. The system confirms the tests fail first, and the builders aren’t allowed to touch them.
  • Sally, our UI/UX designer, writes a design brief before any major front-end work. When the build is done, she reviews screenshots at phone and desktop sizes, including accessibility checks.
  • Bob, Chris, Peter, Wayne and Gord are the builders: front end, back end, database, infrastructure and analytics. Each works in a locked-down sandbox.
  • Steve, the lead reviewer, checks every change against Doug’s spec. He runs on a different AI model from the builder, so he looks at the work with fresh eyes.
  • Sandy, security, reviews anything that touches logins, secrets, uploads or data.
  • Terry, the CI medic and librarian, watches the automated checks, fixes what breaks, and records each project’s lessons so the next ticket starts smarter.

You assign work with a single chat message: “@team, build the medication schedule.” Doug picks it up from there.

What they built

CareBee helps a family circle (adult children, siblings, a spouse, professional caregivers) look after one person together. Our demo covers the whole experience:

  • Onboarding, and inviting family members into the care circle
  • A shared calendar, medication schedules and refills
  • A health record and the care team’s contacts
  • Telemedicine visits, including in-call chat and visit summaries
  • Tasks, settings, plans and billing, and booking services such as rides to appointments
  • A rewards layer, where completing care tasks earns tokens

The numbers:

  • We started from a plan of 11 tickets. We split those into smaller pieces (each kept to about 400 changed lines), and they shipped as more than 20 reviewed pull requests.
  • The full demo went live in nine days, from October 22 to October 30.
  • 155 automated end-to-end checks were passing when it was done.
  • Every screen was tested at normal and 200% text size, because our users’ parents, and often the users themselves, need large type.
  • Each finished feature was copied back into Figma, so the design file stayed in sync with the real product rather than drifting away from it.

Each change went live through the normal pipeline the moment it was merged. Nothing was hand-assembled at the end.

What surprised us

  1. Process matters more than the model. The biggest jump in quality didn’t come from a smarter AI. It came from structure: tests written before the code, a reviewer who didn’t build the work, and a hard size limit on every change. Those are the same disciplines that make human teams good, and they work just as well here.

  2. AI reviewers disagree, so a human has to decide. Steve and Sally sometimes contradicted each other. We set a simple rule: each ticket gets one build and at most one fix pass. After that, the final checks are rendering the app and testing it, and a human decides. AI teams need a tiebreaker, just like people do.

  3. Small tickets beat big ones, every time. When a change grew too large, quality dropped and reviews got noisy. Splitting work into small, verifiable slices was the single most useful habit we built.

  4. Being able to switch models saved us. Partway through, the AI service most of our team ran on hit a billing limit. Because each role was defined independently of any one vendor, we moved the whole team to another provider within a day, and the build kept going. Don’t tie your team to a single vendor.

  5. Accessibility doesn’t have to be an afterthought. Because Sally checks every screen at large text sizes and against accessibility standards (WCAG 2.2 AA), problems were caught ticket by ticket instead of in a painful audit at the end. For a product built for older adults, that matters.

What humans still own

I want to be clear, because the hype gets this wrong. The AI team didn’t replace judgment. It moved it.

People still decided what to build: the pricing plans, the rules for who counts in a care circle, which design to follow when the mockups and the app disagreed. A human verified and approved every merge. And when the reviewers deadlocked, a person made the call.

What changed is where the hours go. Less typing, more deciding. Less “can we build it?”, more “is this the right thing to build?”

If you’re thinking about doing this

  • Define roles, not prompts. Give each agent one job and one standard to meet.
  • Write the tests first. It’s the cheapest quality control you’ll ever buy.
  • Use a different model to review the work. Fresh eyes count, even when the eyes are artificial.
  • Keep changes small. Small changes make both the AI and the human reviewers better.
  • Keep a human at the merge button. Speed is only worth something if you trust what shipped.

We started with a design file and a plan. Nine days later we had a working, tested, accessible product that we can put in front of families.

Doug already has the next spec ready.

I’d love to hear from other leaders who are experimenting with AI teams. What’s working for you, and where are you keeping humans in the loop?

If you want to talk about standing up a team like this, I’m at dan@ctorescues.com. To see CareBee, visit carebeeapp.com.

#AI #SoftwareDevelopment #AgenticAI #HealthTech #Caregiving #Startups #Leadership