It'd be better to start off project with a depreciation schedule on software. Such as discussing plans for ROI after 5 years etc. Past that point, maintenance needs to be considered new work, and billed as a new project.

We've got to stop thinking about software in agile sprints once a product exists. I'm not saying don't use agile for the build. But we've got to learn as software professionals to think like professions that maintain other expensive assets, such as aircraft, ships, or public works. There's a recognition, that a 50 year dam, needs a tear down and replacement in 50 years.

> Every time you decide to solve a problem with code, you are committing part of your future capacity to maintaining and operating that code. Software is never done.

Notice that this includes using code written by other people (e.g., dependencies).

Well, yes, but with possibly different costs. The trick of course is in trying to estimate what they will be.

But using off-the-shelf software that you simply install is certainly one form of "using code written by other people." If it is popular software offered by a stable company, I would always estimate it's likely future cost as less than anything written in-house. (Which doesn't mean it's risk free, the software can become unsupported or change in backwards incompat ways incurring costs. You can get unlucky. But I'm almost always going to advise that it's the safer choice with regard to future costs than in-house development).

If we're talking about in-house software projects to begin with, as you probably intended, but evaluating using a third-party dependency vs writing the functionality in-house, figuring out which of those paths will be likely to end up lower-cost is not at all easy to do, and dependent on a lot of context.

But certainly in all cases, not having any software will be lower-maintenance-cost than having any software. Well, at least lower software maintenance cost. :)