AI can help a small team launch something it couldn’t have afforded to build before. But once a customer depends on it, somebody still has to answer the phone.
That is the part of the small-team conversation I care about. I want more people to have a chance to build a business. I also want that business to be one they can live with.
The work behind the demo
Imagine a design studio with three people. This is a hypothetical example, not a customer story.
A client asks for a portal where they can check progress instead of sending another email. The studio uses AI to help build a prototype. The client likes it, so the studio includes it in the next project.
But a revised delivery date stays in the studio’s meeting notes. Nobody updates the portal. The client plans around the old date and calls when the work doesn’t arrive. Now somebody has to stop designing, work out what happened and repair the trust.
To keep the portal current, the studio tries generating updates from those notes. But the notes mix confirmed decisions with things people only suggested. A fluent summary makes both sound settled.
So the useful change starts earlier. The team needs a place to record what was actually agreed, and a person responsible for changing it. The portal can show that decision. AI can help draft the explanation. Someone still needs to know whether the explanation is true.
The studio wanted fewer interruptions. Without that change, it has given clients another reason to call.
Can we build it?
A prototype we can try.
Can we look after it?
A promise someone owns.
What the pizzas were supposed to mean
Amazon’s two-pizza team model gets remembered for the food: keep a team small enough to feed with two pizzas. But Amazon’s explanation also gives the team a defined area to own, the authority to make decisions and responsibility for running what it launches.
That matters more to me than the headcount. If AI lets a team build with fewer people, the work still needs an owner who can understand it and change it. Calling it a one-pizza team doesn’t settle who picks up when a customer is stuck.
In the studio example, the portal might still be worth offering. But its price and the project plan need to account for keeping it accurate, fixing it and helping people use it. The prototype alone cannot tell the team whether this is a good business.
I learned a version of that with Athlete Builder. We had customers in youth sports. I couldn’t make the economics work. Making something people want and building a company that can keep providing it are different jobs.
Give the team a choice
This is what interests me about AI for small businesses: someone with deep knowledge of a problem may be able to test a solution before they can afford a full development team. That could give more people a chance to own what they build.
But if every saved hour is already promised to a customer, there is no room left to fix a recurring problem or teach someone else the work.
I’m exploring that handoff problem with SkillNav, which is still in development. When a project changes hands, the next person needs to understand what was promised without having to find the founder. I want the tools to help carry that knowledge, with enough context for someone to question the answer.
The right next step might be hiring someone to keep the service dependable, even if AI helped you build it with fewer people. It might be sorting out the handoff so the owner can take a day off. Staying small is useful only if the people in the business have choices.
Before saying yes to the next AI-assisted project, ask who will look after it once a customer depends on it, and what they will stop doing to make room.
Leave room to keep your promises.
Reading that prompted this note: Daniel Bentes’s The Age of the 1-Pizza Team.