Scaling Without Slowing Delivery

Scaling Without Slowing Delivery

June 1, 2026

Maximize the value you ship this week and you’ll minimize the value you ship this year.

This is a dynamic that can happen in growth-stage companies when they continue using startup-stage product engineering approaches long after their effectiveness declines.

Focusing all development efforts on a feature roadmap ordered by urgency makes sense for startups – which need to quickly find PMF, have small user bases and teams, and are developing their codebases from scratch.

But continuing this approach in a scaleup slows delivery rates over time and raises delivery unpredictability.

This in turn slows company growth and makes it vulnerable to competition, even as it appears on the surface to be moving as fast as possible.

Scaleups instead need to adopt new product engineering practices suited to their stage if they wish to sustain delivery speed as they grow.

It isn’t enough to professionalize the business with additional layers of management, team reorganizations, and new departments.

Engineering strategy also needs to be realigned to the realities of a post-PMF company with a large existing codebase forged on the fly during a chaotic PMF hunt.

AI amplifies this. Using AI the way startups do will produce lackluster results and squander opportunities that AI creates elsewhere (which I discuss further here).

In short, you need to engineer your engineering for maximum delivery speed and reliability, using approaches that match the current stage of your product and company.

Maximizing for growth

Delivery speed and reliability affect the two main levers of a scaleup’s growth rate: customer acquisition and churn.

New features improve sales opportunities, and customers who get the features they want quickly – and who aren’t frustrated by bugs and production incidents – will be happy customers who buy more and recommend the product to others.

Customers who are frustrated by the product will instead want to rid themselves of it. Churn is insidious because it’s the fraction of customers who leave over time. Eventually, the company reaches a growth ceiling where customers leave as quickly as they can be acquired – not a growth trajectory investors like to see.

Illustration of effects of churn on SaaS growth, using a fixed rate of customer acquisition.

AI encourages them too, allowing them to quickly and easily build something themselves.

Yes, they’d still have to develop and maintain it, and it’s still easier to use something off the shelf that’s maintained by someone else.

But that equation shifts when a vendor takes months to investigate bugs and simple features get forecast for delivery next year, or the product regularly suffers production incidents. Self-build means I can self-fix and self-extend.

This is why it’s so important for scaleups to sustain their development pace and reliability.

It keeps your customers around rather than plotting to replace your product in-house.

So what differentiates the scaleups that succeed at this from the ones that don’t?

It’s understanding accumulated complexity.

A scaleup's accumulated complexity – in its codebase, processes, and team topologies – sets the pace for every subsequent feature or bug fix. It also determines the frequency of emergent behavior, a primary cause of bugs and production incidents.

A large portion of this complexity is non-essential, existing as a byproduct of urgency and accumulated changes in direction over the company’s lifetime.

And the kicker is this: reducing this accumulated complexity is never urgent, and therefore never gets done unless company leadership integrates it into their strategy.

The curse of urgency is that it slows down the roadmap despite presenting a veneer of “full steam ahead".

Accumulated complexity is worse than you think

Accumulated complexity causes a superlinear decline in development throughput.

Software development is accretive , and each new change needs to fit perfectly within the web of existing logical relationships in the codebase.

Approximate illustration of the dynamics of software development. Effort per feature increases roughly exponentially as excess complexity grows over time, causing a commensurate decline in development pace, if left unaddressed.

This cannot be countered by headcount growth – even if the budget is available – because headcount increases productivity sublinearly .

AI doesn’t counter it either. LLMs are prediction machines. Higher accumulated complexity reduces the likelihood of them guessing the correct next code change.

This leads to longer agent running times which either fail to converge on a solution, produce incorrect changes, or increase emergent behaviour. This in turn increases AI costs.

This combines to create a significant challenge: a scaleup naturally ships slower as time passes due to this accumulated complexity, its competitors (startups and self-builders) start afresh...