What is The True Cost of a Customized Software Solution?

Customized software is a popular choice for many businesses because of its ability to be 100% customizable to your business’ processes and operations. But, the biggest hesitation for companies is the myth of the high cost associated with custom software.

This isn’t always true. The bottom line: custom software solutions do not always cost more than packaged, off-the-shelf, shrink-wrapped solutions. Inevitably, off-the-shelf solutions require a lot of adjustments to be a valuable resource for the company. That can be very costly. In fact, those solutions can turn out to cost more than a custom software package.

One concern of companies who decide on a custom software solution is the maintenance costs.

What do software maintenance costs cover? Why do they exist?

  • To prevent bugs that could interrupt service
  • To improve performance to make tasks faster and more efficient
  • To upgrade features to meet future processes, operations standards, etc. Remember that as your business’ processes improve (as they should), so should your software.
  • To perform data-back up and disaster recovery To cover hosting costs

What is the estimated amount for maintenance costs?

Maintenance costs for customized software usually run a reasonable 15-25% of the project cost. Don’t forget that maintenance fees must also be paid for package software, though it is often worded differently. For off-the-shelf solutions, you will pay for an upgraded version, new licenses, and anytime that you need support.

Custom software is the ideal solution when you have very specific needs for software to fit unique aspects of your business, like a process for selling and tracking those sales which is better than existing off-the-shelf application.

Additionally, keep in mind that when the software project has been well-defined, managed well during the development life cycle and well-tested, you will have minimal maintenance costs.

Lastly, when the project is completed by a professional, knowledgeable company, where the project is on-time, on-budget, and on-spec, the whole solution can provide a very significant ROI, often far in excess of the maintenance costs.

The Custom Software Question: To Build or To Buy?

If you’re like most businesses, you use software on a daily basis for critical functions: managing projects, sending invoices or tracking inventory. The plan for most businesses is to buy a mass market, shrink-wrapped off the shelf (OTS) application, like Quickbooks or NetSuite. And that is a huge mistake. Often OTS solutions only meet 30% of your business’ needs. When the functions are vital to your business and deal with core processes, it is important to use a solution that you are in control of. As software is essential for your business, consider the distinct advantages that custom software has over an OTS solution: Custom software is:

  • A customized glove fit for your business’ specific needs: Before the building begins, the software company sits down with you to understand your processes and then develops the software specifically to your day-to-day functions. In OTS solutions, it is the other way around: you are forced to conform your processes to the software. With a custom solution, you monitor and control the entire process.
  • A solution that comes with local, personalized support: Do you currently have 1 or 2 technical software staff members that support your custom software solution? If one of those team members were to leave, how would your current custom software system be maintained? You’re currently completely dependent on their knowledge of your system. When working with a professional, reputable software company, you have access to an entire team of developers who understand your system and are ready to help.
  • A lower cost than other options: You may be under the impression that custom software is costly. However, on a per-user basis, or when calculating the ROI of the custom software, it turns out to be much more cost-effective than limited OTS solutions. Additionally, once you have hired a company to develop the software for you, you reduce the need to pay for costly individual licensing.

The bottom line? It’s better for your business to create a custom software application, rather than continue to have frustrations, high costs and limitations with your current system.

What methods are used to estimate custom software?

There are two primary methods to estimate and propose custom software projects that we hear about. Those methods are:

  • Fixed cost – The development team may attempt to estimate the time and costs related to creating a software application. The estimates are normally generated using a requirements specification document, which defines what to create in the software application. They may also add some type of fudge factor to the estimate to give them more time in the estimate to complete the project within the estimate. If the time and costs go over the estimates, then the developers cannot charge the customer more than was proposed with the fixed cost estimate.
  • Time and Materials – There may be an attempt to estimate the time and costs of the software project. There may be a written requirements document to use for the estimating. Most often though, the developers will work until the application is complete, and then bill the customer for the time and costs spent.

The Fixed Cost method of estimating and proposing a project can be a good method to use, only if the estimate is relatively accurate, and doesn’t have an excessive fudge factor. If the estimate isn’t accurate then there can be serious trouble in the project. What often happens is that the developers go over their costs and time in the project, and realize they can’t charge more for the project than their additional work, or the customer won’t let them charge more for the project because it was defined as Fixed Cost. Sometimes quality and schedule in the project will suffer significantly. The developers don’t want to continue working on the project essentially for free. But the customer wants the project done. Then the developers will continue work, but the project will become a much lower priority project, because they want to work on paying projects to keep the doors open.

All-in-all it can turn out to be a very tough situation.

Some software development companies can make fixed cost projects work, but there are many more that can’t.

Time and Materials projects are also tough. They can sometimes not work out well because there is little to no clear definition of what software will be created, how it will work, when it will be done, and how much it will cost. The project’s features, cost, and schedule can creep continuously until the customer gets frustrated, cancels the project, and reluctantly pays the costs for time spent on the project.

We have found that what works best is a slight modification of the fixed cost project. That works when:

  • The project plan and software’s requirements are very well defined
  • There are clauses in the project’s contract that requires the customer to pay for changes to the applications features if they requests changes that aren’t in the original requirements specification documents, and
  • When the developers working on the project are experienced and and successful at accurately estimating projects.

We use this last method. We make sure the requirements are well defined, no matter what type of project it is. Our contracts always have the clause which states that if the customer changes the requirements it is a Change Order, and our developers are very good at estimating projects.

When to estimate a software project’s cost?

Here are several questions and answers regarding estimating custom software application projects with companies. This topic is something I have spent a lot of time thinking about over the past years. Keep in mind, the idea here is to start the conversation early about a software project.

Q: When should a software developer or company estimate the cost of the software?

A: As early as possible. Doing so sets expectations and allows the sales process to go forward with the company. And if the numbers are too high, that will be an early indication the company can’t afford a custom software solution. It allows both the developer and the company to move on, or to steer the conversation to a lower alternative solution.

Q: Will the estimates be accurate?

A: No, definitely not. They won’t be accurate until the developer can spend more digging into the project later on in the sales and discovery process, or the early stages of the custom software project.

Q: What happens if the developer under estimated at the beginning of the sales process and the final estimate in the proposal is higher?

A: The developer should be up front and tell the company they didn’t have a chance to dig into the project deeply until now, and this is the actual cost of the project. Hopefully the developer has business processes in place to prevent this from happening, of course.

Q: Can the developer avoid underestimating?

A: Yes, by going really high with their ballpark estimates…but reasonably high…or by doing an early discovery phase to define the problems to be solved with software, and confirm whether a custom software application is the right fit as the solution.


Typically in the initial conversations with a company the company will tell the developer generally what they want in a custom software solution (very high level, no details), and then ask, “So, how much is that going to cost?”

The developer obviously can’t give them an exact cost for a custom software project, right after the developer just heard the high level ideas about the project, and don’t know anything about the details. But if the developer has some experience in the area of custom software development he/she/they can at least take an educated guess.

But, be careful of the educated guess. The developer shouldn’t indicate, nor should the company assume that is definitely the final and total cost. The developer should make it absolutely clear that the educated guess in just that, a guess, that they haven’t had the chance to review the project in detail, etc. The developer has to be honest with with the prospective customer that they are willing to discuss numbers early, but everyone at the table needs to understand the numbers are very preliminary and will very possibly change up or down.

Being honest and upfront like this with a prospective customer can go a long way in establishing a good, trusting bond with them. If they see the developer isn’t afraid to discuss numbers, and they understand that they are very preliminary numbers, then there the conversation can be more open about whether the developer is a good potential fit for the company and the project.

This prevents everyone from spending otherwise wasted time trying to build a business relationship that, had anyone been paying attention to the signs, would have known it wouldn’t have worked out.