There’s a number that keeps coming up in conversations about product teams: three. Three people can now build, ship, and maintain a product that serves thousands of users. Five years ago, that took a team of twenty or more.
This isn’t a hypothetical. It’s how we work at Phantix, and it’s how an increasing number of the best products are being built.
What Changed
The obvious answer is AI tooling, but that’s only part of the story. The real shift is the full stack of leverage available to a small team today.
Infrastructure is a solved problem. You don’t need a DevOps team when Cloudflare Workers and Vercel handle deployment. You don’t need a database administrator when managed Postgres services exist. You don’t need a dedicated frontend engineer when component libraries and design systems are this mature.
AI accelerates the code itself. But the compounding effect comes from eliminating the coordination overhead that large teams require. No standup meetings about meetings. No alignment sessions. No dependency tracking across teams. Three people in a room can hold the entire product in their heads simultaneously.
That’s not a minor efficiency gain. It’s a structural advantage.
The Quality Argument
Small teams don’t just build faster. They often build better.
When every person on the team touches every part of the product, there are no handoff gaps. The person who designed the interaction is the same person who implemented it. The person who wrote the backend logic understands why the frontend works the way it does. Context doesn’t get lost in translation between departments.
This produces a coherence that large teams struggle to achieve. The product feels like one thing, because it was built by people who all understand the whole thing.
The Tradeoff
Small teams can’t do everything. You have to be ruthless about scope. You can’t build a platform — you have to build a tool. You can’t serve everyone — you have to serve someone specific, very well.
For us, that constraint is a feature. It forces the discipline that produces good products. When you can’t throw headcount at a problem, you have to think clearly about whether the problem is worth solving at all.
What This Means for Users
Products built by small, focused teams tend to be simpler, more coherent, and more honest about what they do. There’s no feature added because a product manager needed to justify their role. There’s no complexity introduced because a separate team needed something to work on.
Every feature exists because someone who understands the whole product decided it was worth building.
That’s the kind of software we want to use. It’s the kind we’re building.
