My argument is that the maintenance overhead of a finished product (or car, or building) should require much less effort than what it takes to build it - otherwise you should seek a refund from the original manufacturer(s).
That's absolutely not true in pretty much any mid scale software. You can have a team of 5 people make the core of an app, then need 50 people to help with support for customers. scaling up is never cheap, but software scalability is really low despite that.
That's not even true with a car. I'm about to spend 3000 dollars on a big repair for a car I bought 9 years ago used @ 3500. Even if you adjust for inflation we're still talking about 70% of the car's worth just to keep it running. As for a refund, the blue book value tops at 850 dollars.
> I'm about to spend 3000 dollars on a big repair for a car I bought 9 years ago used @ 3500. Even if you adjust for inflation we're still talking about 70% of the car's worth just to keep it running.
That's one way to run that ROI, sure, but is it correct?
1. The original $3.5k you spent is a sunk cost; you should ignore it, so your total cost of getting a running car is only $3k.
2. Even if you don't ignore it, your total bill to get a running car is $7.5k
In either of the above situations, you should be comparing the cost to get a running car by fixing your existing car (either $3k or $7.5k) to the cost of getting a running car by selling it as-is (so, perhaps +$500 as a parts donor -$X for a replacement running car).
Regardless of which calculus you are using, it's still going to come cheaper to fix the running car.
What the car is "worth" (however you define it) is irrelevant to the calculus.
That actually depends what kind of application you are building and maintaining.
From the sounds of it I assume you're talking about developing and maintaing a SaaS application, where there is no real maintanence of it, and instead what you end up doing is developing it further to support larger data sets and more people. That is of course assuming that the software is successful and the usage is growing.
For traditional desktop software you can declare it finished and then maintanence is minimal and limited to only critical bugs, so you'd have a team of 5 develop it and then 1 person or less maintain it.
