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.