An introduction to maintenance costs for custom software

Building custom software is expensive. It generally involves at least several months of design and development effort, combined with extensive planning and input gathering throughout the organization. Most organizations aren’t prepared for the actual cost of custom software since they don’t take maintenance costs into consideration. Now add headaches, setbacks, and shrinking budgets. Yet, despite all these nuances, we most commonly hear the question: “what is the industry standard for software maintenance fees?”  Let’s dive into a key distinction of custom software development: software maintenance costs vs. software development costs.

Did you know that many projects will ultimately exceed their software cost estimation after the initial launch?

This investment generally happens for three major reasons:

• Refinement to better meet stakeholders’ needs
• Modernization
• Security

These might feel like “no brainers” but it’s common for organizations to skip over software maintainability metrics during planning. I’ve listed these in the order of most immediate apparent value to the organization. Interestingly, they’re also listed in order from elective to mandatory. Let’s look at each of these three areas in turn:

Refinement of custom software to better meet stakeholders’ needs

Your first release of an application is always an approximation. Your team has designed something that you believe has a very good chance of meeting the needs of its audience. But even under the best of circumstances, two things become readily apparent:

• Your approximation is never perfect
• Your audience’s needs evolve

These two factors mean that you’re always aiming somewhat imperfectly at a moving target, and therefore your wish list for your application will never be empty.

Yet this type of evolution is to some extent elective. You can decide the extent to which you want to service it at this level. You can invest more and meet more of your audience’s needs and desires more quickly, but obviously this requires a higher budget commitment. The point is, this is the most visible type of ongoing software development, and it is largely under your control.

Modernization costs for custom software

Custom software is never written from scratch; in today’s world, we stand on the shoulders of giants. Our applications are an amalgamation of many, many components and frameworks. Even a simple application of 2,000 lines of code may have more than 1,000,000 lines of code supporting it. And that doesn’t include the collection of third-party services that most applications now depend on for key functionality. Their inevitable evolution must be accommodated as well.

This foundation provides us with massive increases in productivity. We can now create in several lines of code what used to take us hundreds. And applications that used to take months to build can now be built in weeks instead.

But this rapid rate of progress for software development tools also comes at some cost to the maintenance of the applications that depend on them. Right now tens of thousands of open source developers around the world are continuing to push the state of the art for the tools that underpin our custom applications. When you consider all of the components that an application depends upon, several new releases to the foundation are made every day.

In addition to the tools, software development techniques continue to evolve too (albeit at a much slower pace). The style in which we write web applications now is different — and better — than it was ten years ago.

What does all of this mean for your custom software’s maintenance costs? It means that because these updates are rarely urgent, you do have a choice in terms of when you invest the effort in bringing your software up to date with the current state of the art, and how often. However, since all developers will naturally adapt their skills to the new state of the art over time (while leaving the old tools and practices behind), you don’t have a choice of whether to bring your software up to date. It will have to happen at some point. And just like with dentists and mechanics, the cheapest and least painful thing that you can do is to have maintenance done regularly.

Will you see new capabilities for you users as a result of these upgrades? It’s unlikely. Will performance improve? Probably not. So why do them at all? Because it is the only thing that will keep your software flexible, so that your software development team is able to implement new features quickly and efficiently. And that is one thing that should improve over time — over the years, new features should get cheaper and faster to implement if you stay on top of this type of investment.

Ideally these upgrades are happening continuously, as part of the releases that coincide with new features and capabilities. Your developers don’t need to jump on the latest releases as soon as they come out, but they probably shouldn’t wait more than a year, either.

Security costs for custom software

We’re all familiar with security updates. Our laptops, our phones, and even some of our appliances interrupt us to apply these important changes to their software. While they’re occasionally inconvenient, applying these updates is usually fairly quick and orderly. This is because behind the scenes, a small army of software developers rigorously tested these proposed fixes before packaging them and rolling them out to you.

But with custom software, it’s your software team that needs to go through the same process to develop, test, package, and deploy the same types of updates for your application. This has a much higher cost than when you’re on the receiving end of those packaged updates.

As you can imagine, security updates must usually be developed, tested, and deployed immediately. There’s no time to waste, because your development team got the notification about the existence of the vulnerability at precisely the same time that the dark side did. So it’s a literal race to patch the hole as quickly as possible, before someone figures out how to exploit it.

That’s really the biggest difference with the software development that’s related to security — you don’t get to pick the timeline. It happens immediately, and without notice.

Critical rules of thumb for estimating maintenance costs for custom software

We find that the most useful metric for ball-parking annual maintenance costs is to use the initial development costs as the benchmark. Tally the total design and development cost for getting version 1.0 live. Don’t skimp and stop at the “soft launch” or one of the beta releases. We’re looking for the release that was able to serve its full intended audience. Let’s call this “the cost of the initial launch.” Then, we consider the software maintenance cost percentage.

Here is what our data shows for each category, rounded to the nearest five percent:

• Annual security maintenance: 5% of initial launch
• Annual modernization maintenance: 10% of initial launch
• Annual elective development: 5–30% of initial launch

Keep in mind that you need to budget for each of the categories above — none of them are optional, at least without allowing some aspect of the application to degrade. So your minimum budget for year 2 should be 20% of the initial development costs; that assumes that you’re not making any significant changes or improvements.

These figures assume that the application has been launched relatively recently, or maintained regularly. If your application has been live for some time and hasn’t been maintained regularly, then you will most likely need to invest some up-front maintenance effort to get it back up to speed before you can achieve these numbers.

You’ll note that elective development is never 0%. In our experience you can plan to add zero capabilities to the software for the upcoming year. But we’ve never seen software that’s in production use survive a year without elective changes being necessary. Inevitably some policy will change, or a key user will have a demand that must be satisfied, “or else.” It’s at those moments that the term “elective” feels a little inappropriate. For these reasons, it’s best to budget at least 5% of the initial launch budget for elective development — it will be needed.

What about hosting costs for custom software?

For the vast majority of cases, it’s the human expertise that is expensive and the computers that are cheap. For those that have been in the industry for a while, it’s true that this is the complete inverse of the relationship compared to a couple decades ago.

But now, for all but the most demanding applications, hosting costs are essentially free. Unless you are warehousing massive amounts of data or continuously doing something that is very computationally intensive, your hosting costs are likely to be less than 1% of your overall project budget.

What about customer support costs for custom software?

Unless your software is poorly designed, customer support tends to be more about your audience than it is about the software. If customer support is a significant part of your budget structure, then that’s going to be specific to the situation. Consult with your existing customer support team to estimate those costs.

If you are seeing painfully high support costs due to the software itself, then consider whether there are reliability or usability issues with the software or how it was designed. In these cases you should consider investing in improving the application or its infrastructure as part of the elective development that’s described earlier.

What you can expect from the future

What do the numbers above tell us? That even if you plan to make no visible improvements to the software functionality, you should expect to spend at least 20% of the initial development cost each year, just to keep it up to date with the pace of technology and security, and with the basic needs of your audience. It’s akin to staying in one place on the technology treadmill. You’re just keeping up with inflation. That’s fine, but it needs to be considered part of your software maintenance plan.

At the other end of the spectrum, it also tells us that most organizations are not making radical improvements to their custom software year after year. We generally see a pattern where an opportunity for innovation arises, and a flurry of design and development is initiated to meet that opportunity. This is followed by a couple years of healthy maintenance and modest improvement. It is during this time that the application is really generating its return on investment; where the value that is being delivered to the stakeholders vastly exceeds the maintenance costs.

Inevitably, after a few years a new opportunity arises. The visionaries that sparked the creation of the initial application have had the chance to observe it in actual use, and they again perceive the needs of the future. A new major release is planned, along with the accompanying design and development efforts. If you set up your software maintenance agreement well, this is a smooth and efficient process; it’s often more predictable than the initial release.

That predictability and ability to efficiently respond to change and opportunity is the greatest reward for diligent maintenance of custom software. It greatly increases everyone’s chances for success.

If you have a question about launch or maintenance costs that we didn’t address here, send us an email at team@westarete.com and we’d be happy to chat. We’d love to hear your feedback and make this article more of a resource document for professionals in higher ed IT. If you know someone in your field who needs to read this article, please share it with them. If you’d like to talk with us about our software maintenance and support services, just send us an email and we’ll be in touch.