Should you customize the Off-the-Shelf software application?

Software applications you can buy Off-the-Shelf (OTS) will often fulfill 80% of the needs of a company. If that is true, then what do you do with the other 20% of functionality you need isn’t in that existing software? You need to evaluate what functionality is required by your clearly defined requirements of the application, compare that need to the OTS software application’s capabilities, and make a decision on how to customize or modify the software to meet your needs.
First step is to be cognizant of exactly what you need the software to do. This should have been documented when your company started evaluating off-the-shelf software applications.
Next, compare that to the OTS software solution. How much of your needs does the application fulfill? Do you need a small tweak or is it missing a major piece of functionality you need? Also look at the innate capabilities the software has to allow you or a trained person to modify the software slightly. Many applications come with the capability to make small modifications to the application without breaking the software such that it can’t be continually updated in the future. For example, Zoho CRM and allow you to add new fields to nearly any screen, wrote simple code to perform a calculation or other logical function. Often you don’t need to be a software developer to make those changes. Knowing the limits of the out-of-the-box customization relative to what you need is critical.
Once you have identified how much the software can or cannot be easily customized to meet your needs, you have  three options:
1) Use existing customization features: Go ahead with making the small change to the application using it’s innate customization capabilities. This is the best route if those customization capabilities exist, and if they meet the needs.
2) Modify the application’s code: Modify the code behind the application (i.e., modify the code written by the software manufacturers software developers). I mention this option because the option exists for some software (not all software). But I would never suggest doing this. It can be expensive in the short term and even more expensive in the long term because often the software can no longer be upgraded under existing maintenance plans. You’re then stuck with that version of the software for a long time with little to know support from the software vendor.
3) Create a separate function or application: Create a function or application outside of the application to accommodate the need for the specific feature. This is appropriate when the need for the feature is very significant for the business, and when the complexity of the feature is also significant. You should consider this option very thoughtfully. It has it’s pros and cons. The pros can outweigh the cons in certain situations.
You will likely find that the first option is the best option. However, if you’re in a situation where it doesn’t appear to be the best option, call us. We’d be happy to have some initial discussions with you free of charge.

Can non-geek startups get suitable software solutions?

When you think of a startup company, you often think of young girls and guys who are serious computer geeks that can create a software solution around which to build a great new business

They’re often CMU and Standford grads…people who can create their own, unique web applications, desktop application, mobile apps, etc. Those applications can do all kinds of fun and crazy-cool things. They look awesome and make for a promising and valuable business.

But this idea that only the computer geeks can create a startup is a myth. There are plenty of young people, and not so young people, who have great ideas to start a new business, but aren’t geeks. These people have fantastic ideas, know what needs to be created, but aren’t able to do it themselves.

That’s fine, that’s not a problem. The technical or software solutions can still be created. The question is how. Once you start thinking about the how, a bunch of other questions come up, such as what features, who will do it, how will it be paid for, etc.

I’ll be writing a series of posts on this topic to flesh out the ideas on how startups can get their own technical solutions to startup their business.

The series will follow this approximate trajectory (which may change mid-flight):

  1. What are the technical solutions startups often need
  2. Who can create those solutions
  3. What should be created, and shouldn’t be created
  4. How to get it done
  5. Where will the money come from

Hopefully this short series will be useful.

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.

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.