New companies almost uniformly ship slower than their plans assume, and the pattern holds across industries and team sizes. The cause is that early velocity is measured before the costs that slow it exist.
The first weeks are unrepresentative
At the start there is no legacy code, no customers to support, no contracts to honor and no one to coordinate with. Two or three people can move at a rate that is genuinely unusual.
That period becomes the reference point for planning. Estimates are anchored on the pace of a phase whose conditions have already begun to disappear by the time the plan is written.
Nothing goes wrong to cause the slowdown, which is why it is rarely diagnosed. The work simply acquires obligations it did not previously carry.
Support load arrives with customers
Every customer who signs generates questions, bug reports and requests. In a small team these land on the same people who build, and the interruptions are not scheduled.
Early customers also tend to be the least self-sufficient, because documentation is thin and the product still has rough edges. The support burden per customer is highest exactly when the team is smallest.
Founders often treat this as temporary. It is not: it declines per customer but grows in total, and the accumulated load has to be absorbed by structure rather than by effort.
Maintenance is invisible in the plan
Everything built has to keep working. Dependencies change, integrations break, infrastructure needs attention, and none of that appears on a roadmap written in terms of new features.
The share of capacity consumed by maintaining what exists grows with the size of what exists. A team that shipped four things a month at the start is not lazier when it ships two.
Plans that count only new work will therefore drift further from reality each quarter. The gap widens as the product ages, which is the opposite of what most forecasts assume.
Coordination costs scale with people
Adding people adds communication paths faster than it adds output. Decisions that took a conversation start taking a meeting, and context has to be transferred rather than assumed.
The effect is often felt as a paradox: the team grows and delivery does not, sometimes briefly falling. New hires also consume the time of the people who were fastest.
This is a known and recoverable transition, but only if it is expected. Founders who treat it as a performance problem tend to respond by hiring more, which deepens it.
Decisions slow before execution does
In the earliest phase decisions are cheap because little depends on them. Once there are customers, commitments and internal precedent, the same decisions carry consequences and take longer.
Deliberation replaces reversal as the safety mechanism. That is usually correct, but it lengthens the interval between identifying something and doing it, which reads externally as slowness.
Realistic planning accounts for this by measuring the recent quarter rather than the founding one. The useful baseline is the pace of a team that already carries its obligations.