The One Pizza Startup

← The One Pizza Startup

2026-06-30

Around December 2025, seasoned engineers noticed that frontier coding models now generated consistently high-quality code at a low cost. This has changed the dynamics of starting companies.

Technical founders seem to be realizing collectively that there’s a new path, one that lets a small founding team run more product learning loops each week without adding the comms overhead that usually comes with adding more team members.

The problem: no number of engineers saves a company that lacks product-market fit. Except, the engine of PMF is a tight, compounding learning loop, which requires a focused team and not lots of lines of code written by a large one.

Founding teams need to maximize their probability of growth by getting as many high-quality at-bats as possible before time runs out. Otherwise the paths are failure or being annoyingly diluted, not to mention founder opportunity cost.

This post is intended to start the conversation on how LLMs can change this, using back-of-the-napkin math and thinking.

Pre-LLM startup life

Before LLMs, new startups were told to hire slowly but most never listened. The usual advice as the business scaled was:

Hire a solid team of engineers, and as a technical founder/CEO you free up your time to “run the business” while increasing the probability of creating best-in-class IP, at the expense of reducing your runway. But your team will ship faster.

This IP will then lead to liquidity for all if it’s sufficiently high in value while protecting the downside risks of future financing and team attrition.

Worst case scenario, if the product doesn’t work, the engineering team lands on its feet with an acqui-hire. 1

Ever since Opus 4.7 & GPT-5.5, this line of pre-LLM thinking seems to be fraying.

Inside software companies, the act of changing code to meet customer expectations directly drives growth, and is both the biggest cost and value center.

Pre-LLM, any group of n engineers had (n*(n-1))/2 number of 1:1 communication channels.

A starting founding team of two people had exactly one communication channel, and staggeringly fast execution.

However, as team size grows, the number of channels grows non-intuitively and quadratically while the number of concurrent threads an engineer can handle remains exactly one.

Headcount<br># of comms channels<br>Active threads per engineer<br>Active threads

15

10<br>45<br>10

A growing team’s execution velocity usually slowed down, started behaving non-deterministically and needed more human oversight. Since each engineer could only run one thread, it was crucial to discover what the right changes had to be before anyone touched an editor. So, communications requirements started eating into the time spent modifying code.2

For a team of six, we have six code editors open (one per person) but 15 potential 1:1 communication channels.

Financially, assuming an engineer costs $250k/year, a team of six is $1.5M, which leads to 12-14 months of runway for a $2M seed round after $500k in other expenses. Purely from a financial lens, given the communication requirements, engineering budgets for teams over two people were underutilized expenses.

If you were an especially good founding team, in practice 12-14 months gets you approximately 8-10 months of at-bat PMF attempts before you have to plan next steps if there’s no PMF. At the same time, the engine of product-market fit is a continuous learning loop directly tied to code change velocity post-insights.

Going from seed-stage startup to a robust company was and is quite brutal.

LLMs break the patterns

Like humans, LLMs also behave non-deterministically and need human oversight. However, if an engineering team consists instead of a small number of engineers running many LLM code threads, this materially changes the velocity & survival possibilities for an early startup.

The team structure goes from the O(n²) communication problem to a much more tractable O(n) attention problem of a small team of engineers attending to n concurrent threads in parallel.

Headcount<br># of comms channels<br>Active threads per engineer<br>Total active threads

10

20

15<br>30

10<br>45<br>50

The same team of six now can run 30 concurrent threads instead of six, with a theoretical (but usually not practical) upper cap of 5x the output at double the cost.

The above is a capacity model, not a productivity claim.

Less synchronization is needed since writing throwaway prototypes is now cheap. This speeds up the entire company’s learning loop, which is the primary engine of product-market fit, and gives founders a true dial for maximizing at-bats vs engineering budget.

One pizza for a long time

A “one pizza startup” is a founding team small enough to have a single conversation pair, between two people who can hold the entire product in their heads and use concurrent LLM threads to get more done faster.

Kevin & I have been iterating for a year or so now with this pattern, and...