[andybak]

I actually agree and I should factor that in more.

However for many reasons it's often tricky:

1. This is something you have to address in the initial stages of a client relationship and with price-sensitive clients unused to software development if you're not careful it can sound like you're just rent-seeking.

2. 'Big but infrequent' changes are difficult to cost. Django LTS upgrades are every 5 years. Breaking changes like Python 2 to 3 are even rarer. What figure would I have proposed during the sales process that would have correctly covered me for these? I'm almost certain I would have significantly underestimated.

3. It's not always clear if you're entering into a long-term relationship with the client. They might expect the website to be completely replaced in a year or so, they might be intending to bring development in-house or various other things that make 'saving for a rainy day' a tricky proposition.

[cowsandmilk]

> 3. It's not always clear if you're entering into a long-term relationship with the client.

I've also found that clients will often be acquired, go through management changes, etc that make having these things built in become unstable. One of my clients was acquired by Merck, then Merck sent a letter saying they were terminating all contracts. 18 months later, I get a frantic e-mail from some low-level people asking why I was no longer updating things for them.

The median life of many companies makes building in release->release upgrade support difficult in practice.

[collinmanderson]

I personally charge my clients with a flat monthly maintenance fee which includes upgrades, but also minor bug fixes. In some ways it's a guarantee that the website will keep running, though without an actual SLA. It means I don't need to spend time selling the client on the upgrade.

1. Yes. I always put the on-going fee in the initial project estimate, so there's no surprises.

2. Yes, it requires some guess-work. I've also found that it saves time to take one feature migration (like removing django's url patterns() function) and making that change to all projects at the same time (rather than making all the upgrades to one project at once). I also have found it helpful to reduce the number of 3rd party dependencies. (Fewer things to upgrade, and fewer things that may potentially stop getting supported.)

(Also "Django LTS upgrades are every 5 years" - I was going to correct that to 2 years, but I suppose you can completely skip an LTS line if you time it just right (like, jump from 1.8 directly to 2.0). But you still need to upgrade every _4_ years. Right?)

3. Yes, it's something to figure out initially.

[jsmeaton]

Thanks for the response. I forget sometimes that not all customers are reasonable.