I agree you don't need a large software engineering headcount for maintenance. But there's multiple factors that change the estimate:

  - You need redundancy in case someone leaves, is hit by a bus, gets sick, wants to go on vacation
  - The software is bespoke, so staff need to know the ins and outs of all of it
  - The more software to maintain, more knowledge needed, and more maintenance tasks
  - Poorly built software/systems need a lot more maintenance
  - The business leaders may (erroneously) keep asking for more changes, which creates a greater engineering load
  - If the business value is based on technological capability, you will eventually need radical changes to keep up with new tech

Now, in a few cases, you can cheat. Wordpress requires less maintenance if you rely on canned plugins. But security patching is constant, and eventually you have to upgrade the entire thing as old plugins and core version go EOL. Managed instances help a lot here but still break from upstream changes. And as browsers change, so do the frontend software's compatibility.

The more complex software you depend on, the more expertise you need to fix things. If your usage keeps growing, but your app wasn't designed to scale ("just use Postgres" is not a scaling solution; some things even buying more hardware won't fix), now you need someone to bust open walls and add extensions to the building. That's a lot more dangerous with software contractors than the original engineers.

If your entire stack and app is bespoke, and you run your own VMs, or god forbid, run your own metal, it's a much larger maintenance burden (to keep it running well; lots of people limp along for years on broken equipment and software, at high risk to the business)

If we actually did build software more like we build buildings, we could bring in contractors for short stints to do either maintenance or new construction. But the complexity of current software engineering trends makes that fail a lot of the time.

Replying here because GP makes a good distinction, and your point still holds.

I would point out that there are a few alternate models:

1) You use the maintenance headcount to build, and you just build that much slower.

2) You have an org that wants to stay the same size and move from project to project. In that case, some subset of your staff, are, at any one time, revisiting old projects for updates/maintenance, and some other portion are working on building a new thing. This is probably the strongest paradigm, because you can leverage common platforms between solutions.

Unfortunately, of course, either of this is at odds with the current approach to business/capital, in which once an opportunity emerges, everything is thrown at it as quickly as possible.