Claude Sonnet 4.6

I'm always slightly amused when buzzwords are thrown around vaguely such as "network effect" and "lock in". Those are not entirely a matter of a better sales pitch or bandwagoning. They're about the actual product.

> they will lose to thousands of tiny teams that outship them and beat them on cost

They won't, but this is the actual reason. Nobody likes dealing with support or maintenance, and having to reach out to tiny teams is death by a million papercuts for the end user too. The established players such as Salesforce, ServiceNow, etc. have a mature product that justifies the 7-figure contract price, and there are always lower tiers of the same product for those who are that price sensitive.

I like the "Amazon Basics" analogy.

Also consider that these enterprise platforms are both very expensive and very customizable. Consider SAP which is a huge proprietary mess - including the backing store. An enterprise that buys into SAP is also buying into spending $1M+ a year on consultants.

Open enterprise software will have at it's core open relational database schemas that can be run on the database engine of your choosing. The AI models will be very familiar with those schemas and with the presentation tiers, and will be building a bespoke business app - but not from scratch.

I think the enterprise software consultancies are going to be in trouble. New consultancies will soon emerge who will help move customers off of the legacy platforms.

> They won't, but this is the actual reason. Nobody likes dealing with support or maintenance, and having to reach out to tiny teams is death by a million papercuts for the end user too.

you will have thousands of linear like products eating the slow moving jiras of the world. great small product driven teams, not slop thrown together by your mom

AI raises the ceiling much further than the floor and it raises the floor a ton. the best software, movies, etc will still be produced by experts in their field, they'll just be able to do way more for less.

the bottleneck at large orgs is communication already, this will get even worse when time to produce stuff goes way down. big cos will drown in slop and are probably better off starting from scratch

The question is "open source" vs "proprietary". Open source will become the majority of SaaS. But the industry needs to find the right business model. I think the model will look, to the enterprise clients, largely the same as today. There will still be usage costs (both per user and storage) and support costs. But there will not be "license costs". And there will be much less lock-in.

1. The default outcome: fewer people, same output (at first) When productivity jumps (e.g., 5–6 devs can now do what 10 used to), most companies do not immediately ship 10% more or make things 10% better. Instead, they usually:

Freeze or slow hiring Backfill less when people leave Quietly reduce team size over time

This happens because:

Output targets were already “good enough” Budgets are set annually, not dynamically Management rewards predictability more than ambition

So the first-order effect is cost savings, not reinvestment.

Productivity gains are initially absorbed as efficiency, not expansion.

2. The second-order effect: same headcount, more scope (but hidden) In teams that don’t shrink, the extra capacity usually goes into things that were previously underfunded:

Tech debt cleanup Reliability and on-call quality Better internal tooling Security, compliance, testing

From the outside, it looks like:

“They’re building the same amount.”

From the inside, it feels like:

“We’re finally doing things the right way.”

So yes, the product often becomes “better,” but in invisible ways.

3. Rare but real: more stuff, faster iteration Some companies do choose to build more—but only when growth pressure is high. This is common when:

The company is early-stage or mid-scale Market share matters more than margin Leadership is product- or founder-led There’s a clear backlog of revenue-linked features

In these cases, productivity gains translate into:

Faster shipping cadence More experiments Shorter time-to-market

But this requires strong alignment. Without it, extra capacity just diffuses.

4. Why “10% more” almost never happens cleanly The premise sounds linear, but software work isn’t. Reasons:

Coordination, reviews, and decision-making still bottleneck Roadmaps are constrained by product strategy, not dev hours Sales, design, legal, and operations don’t scale at the same rate

So instead of:

“We build 10% more”

You get:

“We missed fewer deadlines” “That migration finally happened” “The system breaks less often”

These matter—but they’re not headline-grabbing.

5. The long-run macro pattern Over time, across the industry:

Individual teams → shrink or hold steady Companies → maintain output with fewer engineers Industry as a whole → builds far more software than before

This is the classic productivity paradox:

Local gains → cost control Global gains → explosion of software everywhere

Think:

More apps, not bigger teams More features, not more people More companies, not fatter ones

6. The uncomfortable truth If productivity improves and:

Demand is flat Competition isn’t forcing differentiation Leadership incentives favor cost control

Then yes—companies are content to build the same amount with fewer people. Not because they’re lazy, but because:

Efficiency is easier to measure than ambition Savings are safer than bets Headcount reductions show up cleanly on financials