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

The Short Version

Four builders who work at very different scales describe the same pattern: 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. Pieter Levels runs profitable products entirely alone and replaces staff with automation [1]. George Hotz came away from Twitter convinced that 50 people could build and maintain it [2]. Dario Amodei argues that talent density beats talent mass, because a larger, diluted group loses trust and grows politics [3]. Aravind Srinivas, borrowing from Larry Page, Jeff Bezos, Elon Musk and Jensen Huang, builds Perplexity around a few obsessed people, bold hires and the removal of unnecessary problems [4]. They do not agree on how small is small, and the sources are clear that the approach has limits.

Table of contents

What They Said

Pieter Levels: a team of one

Levels is the extreme case. "I don't really raise money. I don't use VC funding. I do everything myself," he says: he is the designer, the developer and the logo maker [1]. He has built and launched over 40 startups, mostly alone [1]. He contrasts this with the usual venture path of raising money, hiring and then searching for a product [1].

His method follows from having no funding. He builds a mini startup, launches within about two weeks, and checks whether people will take out their credit cards; most ideas fail, and that is expected [1]. The habit came from his 12 startups in 12 months challenge, each launched publicly with a Stripe payment button, which taught him to code and forced him to cut features to fit a month [1]. Avatar AI launched with just an HTML page, a Stripe payment link and a Typeform for photo uploads, and he trained the first few hundred models by hand until the workload forced him to automate [1].

Levels's explanation for why one person can outrun a giant is bureaucracy. Big organizations like Google, which invented transformers but never shipped a ChatGPT, get slowed down, he argues, while he can ship from a hotel room without asking legal for approval [1]. Founder friends who raised hundreds of millions privately tell him they would rather work his way, because they miss building and do not enjoy being managers [1].

Three practices keep the team at one:

• Simple, familiar tools. He builds everything with vanilla HTML, JavaScript with jQuery, PHP and SQLite, and says PHP "just stays the same and works." [1] He insists tools matter less than knowing them well [1].
• Automation in place of staff. Nomad List meetups are scheduled, announced and messaged automatically, and his sites run on cron jobs [1]. Health-check pages show green or red emoji, Uptime Robot watches for red and alerts him on Telegram within a minute, and every PHP and JavaScript error goes to Telegram too [1]. He moderates a 10,000-person chat and fights spam with GPT-4 [1].
• No gap between writing and shipping. He deploys straight to production, pushing to GitHub and live in seconds, with around 37,000 commits in 12 months. "I'm gonna be canceled for this," he jokes, but it lets him fix reported bugs within minutes [1].

The economics are part of the argument. He keeps margins high by not hiring and by asking vendors for discounts [1]. Solo makers, he says, should aim for $30 or more per user, and a thousand paying users at that price is enough to live well [1]. Interior AI made $10,000 to $20,000 a month within a week and still makes $40,000 to $50,000; Remote OK peaked around $140,000 a month in 2021 [1].

George Hotz: fifty people could run Twitter

Hotz's lesson comes from the inside of a large codebase. After his short internship at Twitter he said, and still says: "I still believe in the amount of hate I got for saying this that 50 people could build and maintain Twitter." [2] His explanation for the hostility is that if doing things were possible, some people would "have to do some soul searching." [2]

He locates the problem in incentives and accumulated code, not in individual engineers. Twitter's promotion system, he found, rewarded writing libraries others used, such as an Nginx replacement nobody needed [2]. He ranks code quality at Facebook first, then Google, then Twitter [2]. Of Google he says there are a lot of really good software engineers but the codebase is very large: "There's so many products, so many teams, right?" [2]

His main technical recommendation to Elon Musk was "refactors before features." [2] The plan: first build tests you trust, especially a replay system at the service boundaries like comma's process replay, then replace large modules with simpler code as long as the tests pass [2]. He says such a refactor could take six months to a year and make feature development ten times faster [2].

His own companies apply the same taste for smallness to code. Tinygrad builds everything from about 25 operations, compared with roughly 250 for PrimTorch and about 2,000 kernels in PyTorch, and runs LLaMA and Stable Diffusion in about 2,700 lines [2]. At comma, engineers must explain their code, and if he sees a simpler way, they rewrite it; he calls the company a transparent dictatorship with free exit [2]. Comma is profitable, has about 5,000 daily active users and builds its boards in-house [2]. At tiny corp, the only way to get a job is to contribute on GitHub [2]. And he is skeptical of tools that paper over bulk: if Copilot saves you lots of boilerplate, he says, your framework is probably bad [2].

Dario Amodei: density, not mass

Amodei supplies the general principle. Asked about his line that talent density beats talent mass, he offers a thought experiment: 100 superb, mission-aligned people versus 1,000 people of whom only 200 are like that [3]. In the larger group, trust erodes, processes and politics multiply, and fiefdoms form [3].

He does not conclude that a company should stay tiny. Anthropic grew from about 300 to 800 people in seven or eight months, then deliberately slowed, adding only around 100 to 150 in the following three months [3]. The company hires many theoretical physicists because they learn fast, and the top quality he looks for is open-mindedness, the willingness to see with new eyes [3].

His own story is offered as evidence of what matters in a person. He says he was not a better programmer than his colleagues; he just asked what would happen if a 30-million-parameter network got 50 million, and plotted graphs [3]. He also says Anthropic's advantages are usually not secret methods but trade craft: better infrastructure, better data, better filtering [3]. And he describes leaving OpenAI in similar terms: arguing with someone else's vision is unproductive, so it is better to take people you trust and run a clean experiment [3].

Aravind Srinivas: what great founders do with small teams

Srinivas describes his approach as an "ensemble algorithm" over many founders [4]. Several of the lessons he took bear directly on who you hire and how they work.

From Larry Page and Sergey Brin he admires the decision to hire PhDs cheaply during the dot-com bust, along with Page's obsession with latency, including testing Chrome on old laptops [4]. Srinivas tests Perplexity on in-flight Wi-Fi and sweats details like the cursor being ready in the search bar [4]. From Bezos he takes clarity of thought and the one-way versus two-way door framework, with a hiring corollary: do not agonize over an extra $20,000 to $30,000 for a hire who could transform the company [4]. From Musk he takes raw grit and doing any work yourself, like data annotation [4]. From Jensen Huang he takes obsession with detail, large group meetings instead of one-on-ones, and paranoia; Huang told him he wakes up worried about going out of business [4].

Perplexity itself began with three people, Srinivas, Denis and Johnny, who wanted to build cool LLM products [4]. Their first investor told them to focus on a narrow wedge first [4]. They were obsessed with search before the company existed, so improving search quality itself was the reward: "Where do you get your dopamine from?" he asks [4]. The company runs on AWS instead of its own data centers, which he says frees the team from unnecessary problems and makes hiring easier [4]. It uses other companies' models alongside its own, and he says it does not matter whether Perplexity is a wrapper, because what matters is that the answer works [4].

Where They Agree, and Where They Don't

They agree that the quality of individuals outweighs their number. Amodei says it outright [3]. Hotz's 50-person claim [2], Levels's solo record [1] and Srinivas's advice to pay up for a transformative hire [4] all rest on the same belief.

They agree that organizational weight is the enemy of shipping. Levels blames bureaucracy and legal approval [1]. Hotz blames promotion incentives and sprawling code [2]. Amodei blames eroded trust, process and fiefdoms [3]. Fridman adds his own contrast with slow-moving teams at YouTube and argues for leaders who give engineers the power to ship [1].

They agree that simplicity is a strategy. Levels uses the tools he already knows [1], Hotz deletes code until it can be reasoned about [2], and Srinivas avoids running data centers [4].

They agree that builders should stay close to the work. Levels does everything himself [1], Srinivas admires founders who will do data annotation [4], and Hotz reviews and simplifies his engineers' code [2].

They differ on how small. Levels means one person [1]. Hotz means dozens [2]. Amodei runs a company of nearly 1,000 employees and frames the issue as a ratio, not a headcount [3]. This is not a contradiction so much as a difference in the work: Levels ships web products built on other companies' models and infrastructure [1], while Amodei describes frontier models that cost around $1 billion to build and need months of training on tens of thousands of chips [3].

They differ on process before shipping. Levels deploys straight to production [1]. Hotz wants trusted tests first, then change [2]. Amodei describes internal safety testing and external testing before a model is released [3].

They differ on governance. Hotz calls comma a transparent dictatorship with free exit [2], while Amodei emphasizes mission alignment and trust among the people hired [3].

Why It Works

Trust scales badly. Amodei's mechanism is the clearest: once only a minority of a large group is excellent and aligned, trust erodes, and process and politics grow to fill the gap [3].

Fewer people means fewer approvals. Levels's speed comes from having nobody to ask [1]. It also shortens the feedback loop: a reported bug can be fixed within minutes [1], and a parameter change can be tested on 10% of users and judged by which photos people favorite or download [1].

Large organizations reward the wrong work. Hotz saw promotions go to people who wrote internal libraries nobody needed, which adds code without adding value [2].

Simple systems can be held in one head. Tinygrad's small set of operations is meant to make everything something that can be reasoned about [2]. Levels's stack stays the same, so his knowledge of it compounds [1].

Automation and outside platforms stand in for employees. Cron jobs, alerts and GPT-4 moderation do the work of staff for Levels [1]; Replicate does his model training [1]; AWS and third-party models do the same for Perplexity [4].

Constraints force focus. Without funding, Levels has to move fast and cut features [1], and he concludes more generally: "I think constraints probably make you happy." [1]

The evidence is experience and outcomes: Levels's revenue figures [1], comma's profitability [2], Anthropic's deliberate slowdown in hiring [3], and Perplexity's growth from a three-person start [4]. None of the four cites a controlled comparison.

Where It Applies, and Where It Doesn't

It applies to software products where one person or a handful can reach users directly, charge from day one and lean on existing platforms [1][4]. It applies to rescuing a bloated codebase, provided there are tests to trust first [2]. And it applies to hiring at any size, as a rule about ratio [3].

It does not make every problem a small-team problem. Frontier AI models, on Amodei's numbers, need enormous capital and long pre-training runs, and Anthropic employs nearly 1,000 people [3]. Srinivas says Google itself is not in danger and has nailed ten-link search for 20 years [4]. Hotz says Tesla has always been about two years ahead of comma and will probably stay there, "because they're not doing anything wrong." [2]

It does not suit every style of working. Fridman notes that pushing straight to production is very different from how teams at large companies operate [1], and Levels himself jokes about the practice [1]. Hotz admits he is not the right person to run Twitter [2].

It has costs for the person. Levels is open about loneliness and depression on the road [1]. Srinivas says most scenarios for a founder end in failure [4]. Small teams also get copied: after Avatar AI made about $150,000 in a week, larger players like Lensa copied the idea and, Levels believes, made around $30 million [1].

What To Do With It

1. Hire for density. Use Amodei's test: would you prefer 100 superb, mission-aligned people or 1,000 with 200 of them mixed in? Slow hiring when growth outpaces trust, as Anthropic did [3].
2. Look for open-mindedness and learning speed, not credentials alone. Amodei names open-mindedness as the top quality and hires people who learn fast [3].
3. Pay for the hire who could transform the company. Srinivas, citing Bezos, says not to agonize over an extra $20,000 to $30,000 [4].
4. Launch small and charge immediately. Levels's first version of a product was an HTML page, a payment link and a form [1].
5. Use the tools you already know. Levels's stack is old and simple, and he says knowing tools well matters more than which ones they are [1].
6. Automate before you hire. Set up scheduled jobs, health checks and alerts so the product runs with little human work [1].
7. Refactor before adding features, and build tests you trust first. That is Hotz's order of operations for a large codebase [2].
8. Ask engineers to explain their code, and rewrite when a simpler way exists. Hotz applies this rule at comma [2].
9. Remove problems that are not yours to solve. Perplexity rents its infrastructure so the team can stay on the product [4].
10. Work on something you would do anyway. Srinivas's question is where your dopamine comes from [4]; Levels was building things long before they made money [1].

Sources

1. Pieter Levels on Building Solo Startups, Photo AI, Simple Code and Digital Nomad Life · Lex Fridman Podcast
2. George Hotz on tiny corp, tinygrad, Open-Source AI Safety, Self-Driving, and Twitter · Lex Fridman Podcast
3. Dario Amodei: Anthropic CEO on Claude, AGI, the Future of AI, and Humanity · Lex Fridman Podcast
4. Aravind Srinivas: Perplexity CEO on Future of AI, Search & the Internet · Lex Fridman Podcast