Small teams, high talent density: how lasting software gets built

Software gets built well by a small number of very capable people who can ship without asking permission, and it degrades when headcount, process and layers pile up. Four builders at very different scales describe that pattern. They do not agree on how small is small, and the approach has clear limits.

Pieter Levels is the extreme case, a team of one. He raises no money and does the design, development and everything else himself. He has launched more than 40 products, mostly alone, each within about two weeks to see whether people will pay. He blames bureaucracy for slowing big companies, while he can ship from a hotel room without asking anyone. Three practices keep his team at one: simple tools he already knows, automation in place of staff, and no gap between writing code and releasing it. He is open about the costs, including loneliness and being copied by larger players.

George Hotz learned his lesson inside a large codebase. After a short stint at Twitter he said, and still says, that fifty people could build and maintain it. He blames incentives and accumulated code, not individual engineers. Promotions there rewarded writing internal tools nobody needed. His advice was "refactors before features.": build tests you trust, then replace large parts with simpler code. In his own companies, engineers must explain their code and rewrite it when a simpler way exists.

Dario Amodei, who leads the AI company Anthropic, supplies the principle that talent density beats talent mass. Compare 100 superb, mission-aligned people with 1,000 of whom only 200 are like that. In the larger group, trust erodes, and process, politics and fiefdoms grow. He does not conclude a company must stay tiny. His grew fast, then deliberately slowed hiring. The quality he most looks for is open-mindedness.

Aravind Srinivas, who leads the search company Perplexity, borrows from well-known founders. He would not agonize over a bit more pay for a hire who could transform the company. His firm began with three people obsessed with search, and it rents its computing so the team is freed from unnecessary problems. His question for anyone choosing work is "Where do you get your dopamine from?"

They agree that the quality of individuals outweighs their number, that organizational weight is the enemy of shipping, and that simplicity is a strategy. They differ on size, from one person to dozens to nearly a thousand, and on how much testing should come before release. Frontier AI models need huge capital and many people, so not every problem is a small-team problem. The evidence is experience and outcomes, with no controlled comparison.

What to do with it: hire for density, and slow hiring when growth outpaces trust. Look for open-mindedness and learning speed. Pay for the hire who could transform the company. Launch small and charge immediately. Use the tools you already know. Automate before you hire. Refactor before adding features, with trusted tests first. Ask engineers to explain their code. Remove problems that are not yours to solve. Work on something you would do anyway.