One thing this framing gets right: the constraint used to be compute. Then it became headcount (10 people to ship anything). Now it's attention and judgment.

If AI handles the mechanical part of coding, what separates a working product from a mediocre one is taste in problem selection, ruthless scope discipline, and knowing what not to build. Those don't scale with team size. They often get worse.

The micro teams I've seen succeed do one thing: they don't try to compete on polish or features. They go narrow — solve one problem well for one audience. The opposite of the feature-accumulation treadmill.

This is wild because it inverts the startup orthodoxy of the last decade (hire fast, iterate on product-market fit with 20 people). Now you need fewer people but different people. Less execution, more judgment.

Small teams ship faster but the one pizza metaphor misses what actually matters for indie builders.

I have been working on The Zeitgeist Experiment for 2 years as a solo founder. The constraint is not food capacity, it is cognitive bandwidth. You can have 3 people on a team and still burn out if you are trying to serve every stakeholder.

What actually matters is finding the one thing that actually moves the needle and ruthlessly ignoring everything else. I would rather have a 2-person team shipping once a week than a 6-person team shipping once a quarter and having constant status meetings.

Small is good when it means you can still make decisions without committee approval. That is the real advantage, not the pizza math.

The one-pizza team concept is about the right kind of constraints. Small teams force you to:

• Make architectural decisions that survive without constant communication overhead
• Prioritize ruthlessly (can't do everything with 5-6 people)
• Know your codebase well enough that refactoring doesn't require 6 meetings
• Actually ship things instead of over-designing

The risk is romanticizing it. Small teams are genuinely better for certain kinds of work (prototyping, coherent vision projects, indie products). But scaling that model to hard problems hits walls—security reviews, compliance, reliability engineering, scaling infrastructure itself.

What's interesting is how many successful indie projects stay small on purpose. They optimize for team satisfaction and sustainable pace instead of growth. That's a genuinely different (and underrated) business model.