The Smallest Complete Team. A Better Model for AI-Era Software Development

Pieoneers team working together in Vancouver. Shared context and direct communication are central to the smallest-complete-team model.

The Smallest Complete Team: A Better Model for AI-Era Software Development

Andrew, our CTO, and I were talking this week about the two-pizza team idea.

The rule, famously associated with Amazon, is that a team should be small enough to feed with two pizzas. We then came across the argument that a one-pizza team might be even better.

I'm skeptical, if only because one pizza is barely enough for two people in our house. My teenage son can probably eat most of a large one himself.

But it got us talking about a question we've been thinking about for years: How many people does it actually take to build a great software product?

The Two-Pizza Team Is a Starting Point, Not a Formula

At Pieoneers, we've generally worked with small project teams. Two or three senior engineers is common. Five to seven is a large team for us, and we normally have several projects running in parallel.

We didn't set out to prove that small teams were better. This was simply the way we learned to work. But over the years we've seen many situations where a small, senior, cohesive team could move faster than a much larger one.

I think the important word here is complete.

A complete software team has enough product understanding, technical breadth, decision-making authority and delivery capacity to own the problem from beginning to end.

What Makes a Small Software Team Complete?

Two engineers aren't inherently better than ten. They're better only if those two people have enough experience, context, autonomy and breadth to solve the problem without continually handing work off.

In our strongest teams, each engineer understands the product, not just their part of the code. They know the codebase. They can make architectural decisions. They communicate directly. They can cross the traditional boundaries between frontend, backend, mobile and infrastructure. Today, they also use AI extensively.

There is another reason these small teams work for us. We rarely build products in isolation.

Our customers tend to be experts in the problems they're solving. They may be founders who have spent years thinking about an idea, researchers with deep knowledge of their field, healthcare professionals, or leaders inside established companies who understand their customers and operations better than we ever could.

They bring the domain expertise. We bring product and engineering expertise.

Together, that can make a surprisingly small but complete product team. This model works particularly well for founders, researchers and established organizations that already understand their domain but need an experienced product and engineering partner to turn that knowledge into reliable software.

Why Coordination Grows Faster Than Headcount

There is also some simple mathematics working in favour of smaller teams. Two people have one possible communication relationship. Three have three. Five have ten. Ten have 45.

Of course, real organizations don't work exactly like that. Not everyone needs to communicate with everyone else. But anyone who has worked on a large software team knows the underlying problem: as a team grows, more of its energy goes into coordination.

More engineers provide more capacity, but they also create more handoffs, dependencies, meetings, onboarding and opportunities for context to get lost.

When a Small Team Becomes Too Small

That doesn't mean smaller is always better.

Some products have enough independent workstreams to keep dozens or hundreds of engineers productive. Small teams have risks too. They can lack an important skill, become dependent on one person, or simply not have enough capacity.

How AI Is Changing Software Team Size

And AI creates a new version of this problem that I think technology leaders need to be careful about.

There is enormous pressure right now to show that AI is making engineering organizations more efficient. If three AI-enabled developers can theoretically do what six used to do, it is tempting to make three the target.

I think that's backwards.

AI can change what a small team is capable of, but the problem still has to determine the team.

What Small AI-Enabled Teams Look Like in Practice

We've been seeing the positive side of this in our own work.

A small Pieoneers team has worked for years with researchers at UBC on the Database of Religious History, a substantial international research platform. When we undertook a major modernization of the platform recently, the combination of senior engineers who already understood the system and modern AI development tools changed dramatically how quickly we could approach the work.

Jevitty is a very different example. Its health platform has involved native iOS and Android applications, web software, cloud infrastructure, wearable and health data, and medical-imaging integrations. Again, the core engineering team has remained relatively small.

These projects have made me think that headcount may not be the most useful way to think about a software team's capacity.

Capability Density: A Better Measure Than Headcount

A better concept might be capability density: how much domain knowledge, product understanding, technical judgment and ability to execute exists within the group actually solving the problem.

A Small Core With a Deep Bench

There is one more part of this that matters. A small core team doesn't have to mean a small pool of expertise.

Our projects tend to have a few people who hold most of the product context and make the day-to-day technical decisions. When they need deeper expertise in AI, infrastructure, native mobile, security or UX, they can bring someone in without permanently adding another person to every meeting and every decision.

We've come to think of this as a small core with a deep bench.

AI is making that model more powerful. A strong engineer can investigate unfamiliar territory faster, prototype ideas faster and automate a lot of routine implementation. But AI doesn't remove the need for judgment. Someone still needs to understand the problem, decide what should be built, recognize when an approach is wrong and take responsibility for the result.

So I'm not convinced that the future belongs to one-pizza teams. I'm not even convinced that two pizzas tell us very much.

What I am increasingly convinced of is that we should look for the smallest complete team: small enough to share context and communicate directly, experienced enough to make good decisions, broad enough to own the product, and large enough to do the work well.

Finding the Smallest Complete Team for Your Product

AI may change where that line sits.

It doesn't make the line disappear.

If you're planning a new product, modernizing an existing platform, or exploring how AI could change the way your team builds software, we'd be glad to help you determine what the smallest complete team could look like.

Tell us what you're building.