Why Is It Impossible to Estimate Software Development Costs Properly

It won’t be an exaggeration to say that preparing a reliable software development cost estimation is an art. It needs a lot of experience and years in the software development business to do it right; even then, it’s impossible to do that precisely.

Why? In this article, I’ll explain all the nuances behind estimating projects and give hints on how to evaluate the cost estimates you receive in order to choose the best software developer for your project.

The type of software project contract vs estimation accuracy

There are two most common contract types: Fixed-Price and Time&Materials. I’ll explain the difference according to estimations. Still, I won’t dive deep into the distinction as you can read more in articles about comparing different software development billing models and investigating the risks and challenges of Fixed-Price contracts.

Both types of contracts are suitable for different projects, and therefore, the costs are assessed differently.

It’s tough to estimate Fixed-Price contracts correctly, even with many years of experience. A digital product development agency handles the entire financial risk and it’s almost certain that the project’s requirements will change. For this reason, a software developer needs a vast margin of error, even if requirements are defined in detail. The practice proves that the outcome is far from the previous assumptions and that projects change throughout the software development process. That makes costs significantly higher and the estimation unacceptable compared to T&M contracts (and that’s perfectly normal).

T&M cost estimates are more reliable and can be applied to projects at every stage of the development process and every size. It’s worth remembering, however, that its reliability depends on many factors, and a list of features is only one of them.

Below, I’ll focus on T&M contracts.

What does the estimation accuracy depends on?

There are four main elements that affect the accuracy of software development cost estimation, and now we’ll take a look at each one of them.

  1. Software House experience
  2. Requirements specification
  3. Expected results
  4. Future project’s evolution

Software House experience

Experience matters, and there’s no difference when it comes to estimating software development costs. The more experienced project managers and the more similar projects has a company built before, the more accurate software development cost estimation they can prepare.

There are three types of features: classic ones and easy to estimate, features traditionally difficult to assess their time and highly custom and unpredictable.

Features that are not defined precisely enough are traditionally difficult to assess. The point is that a project manager needs to make a lot of assumptions about what the client wants to build. What they can do (especially when a client comes with nothing but an idea) is to set as a point of reference another app they have made before.

There’s always the dilemma of whether to provide the client with a reasonable but higher cost estimate or focus only on the initially mentioned features. Although we know that the first one will still be uncertain, the second will definitely be too low (but more competitive and comparable to other offers clients will gain from the market). We’ll get back to this dilemma later.

Classic and easy-to-estimate features are common ones. They are a part of most apps (like signup, login or simple admin panel) and can be estimated even with a loss of up to 10%. There’s also only a tiny probability of complications.

The final group are highly custom and unpredictable features like integrations, parsing or processing of different form of data that can always cause problems. For this reason, you’ll likely get a range of software development costs rather than one value. The exact amount you pay will be up to the number of issues the development team encounters on the way.

The case is that those are features that can be implemented quickly and easily because they are well-documented and smoothly working, or that might be just appearances. In fact, the documentation needs to be updated, or the solution needs to be more robust. In such cases, the time required to contact support or look for other solutions takes time and affects the estimation and final software development costs.

The more experience a software development company has in building such solutions, the less probability of misestimating the entire project costs. The fact is that many basic integrations can be classified as classically easy tasks. The problem appears when requirements are highly customised, even in the case of well-known systems and solutions.

How to handle that?

Unfortunately, you have no impact on the project manager’s and company’s experience. All you can do is provide them with the most detailed list of features that you want to be featured in your app as possible (see the next section).

Requirements specification

The software development cost estimation is as accurate as the input from the client: the more detailed the app description is, the more precise estimation you can expect.

That’s the theory. In reality, you might have nothing but an idea. That’s okay, but it makes the estimation harder to prepare.

Even if you have some requirements, they might need to be more detailed. In fact, 8 out of 10 people still need to build user stories, and less than 5% passed through the discovery phase first. That’s perfectly normal, but it leads us to another problem.

Let’s say you want to build an Uber-like app. What features should your app have? You would say a map, searching for drivers and payment. That’s the most apparent, crucial and noticeable features, but are those the only ones you need?

The main problem is that when it comes to defining how the app should work, people need to remember about additional, interconnected features. That’s also perfectly understandable, as they don’t have any experience in app development and don’t know (and don’t need to know) all the nuances of the process. That’s our job to explain it.

Let’s get back to an Uber-like app. Do you think that the features described above are enough to make the app work? How will drivers know that someone booked a ride? What happens when someone forgets their password or wants to delete the account?

Another aspect to consider is payment. What if a client changes their mind and wants to cancel the tour? How to handle cash backs, appellations, complaints and all the elements required by the law? From this perspective, one feature has grown into four and so has the software development cost.

Those elements are apparent, but no one thinks about them when planning the app. Settings, security or refunds are necessary but unnoticeable. It’s the role of an app development agency to explain how applications are developed and help clients go through the process.

In fact, basic functionalities that don’t bring us any value for users (and we don’t think about them) account for around 30% of a regular, middle-sized app. Building a technical architecture of the project, an admin panel and fundamental user flow (authentication and logging in) lasts about 2-4 weeks, and after that, we still need a feature attractive to users. We only have a must-have base.

How to handle that?

As I mentioned above, the more precise you gather the requirement, the more reliable cost estimation you receive.

It would be best if you had some conclusions from the discovery phase, including a detailed description of features, user stories, and visual representation of possible actions users can take in the app. If you don’t have those, you should not invest in designs, as they will change hand in hand with changing requirements.

If you don’t have that, you have two options: go through the discovery phase or define the requirements yourself. If you want to do that alone, think carefully about those aside features connected with the ones you need (it’s a challenge, I know that). It would be best if you also wrote down the app’s main actions users can perform.

I recommend running the discovery phase in two main cases: you have nothing but an idea, and you need an exact estimation. During the discovery phase, you, hand in hand with your product development agency, will define who your clients and users are, what they need and how to build the app to suit their needs. You’ll create buyer and user personas and user stories and prepare a development plan. The discovery phase will also reveal the assumptions about the results (see below).

The discovery phase is an investment that pays off almost immediately. First, you’ll get a deep insight into what you want to build and why and assess whether that idea may succeed on the market. The second benefit is that you save money on further stages as you already know what to do and don’t need to pay for changing an ongoing project.

The third and most beneficial when we’re talking about estimations is that you can test your potential contractor. You don’t have much to lose – if the cooperation doesn’t suit your needs, you can take the discovery phase outcome and search for another software development company.

Expected results

The third element that affects the estimation is expectations. It matters what result you want to achieve because when it comes to software development, almost every feature can be done in a simple or complex manner.

Simple solutions can be built quickly and won’t be perfect, but they are an ideal match for new projects and MVPs. More advanced ones require more time and, therefore, money, so they are appropriate when you have a higher budget or constant income from the previous version of the app.

How to handle that?

Share your needs with the potential contractor and trust in their experience. Share your budget. A reliable partner will always take care of what’s best for the project and can advise other, better solutions that are within the budget but will provide a better value.

Even if it comes to an Uber-like app, it makes a difference whether it will be an MVP or a complete product. MVP can be made with a lower level of complexity and without custom designs to reduce the cost and verify the idea behind the app. It doesn’t need to be perfect, but it should be fully working and functional.

Future project’s evolution

If you ask me, there’s one constant in software development – everything changes. Then how to estimate software development cost?

Every cost estimation is based on requirements, but no one knows what the final app will look like and how many changes will be made during the development process. From my experience, every single project evolves. The problem with estimations is that we don’t know whether the app we’re estimating will be the same one that will be launched. It’s likely that certain features will be added (and some deleted) from that equation (and cost estimate).

As a client, remember that the estimation always refers to the product we’re discussing now and will change as the app changes. Projects are constantly evolving, and that’s a good thing – it allows us to adjust to market demand and trends, adjust apps to users’ needs and preferences after feedback was collected and, overall, make a better product.

Although experienced companies can assess the costs of those changes and add a safety buffer to the estimation, that’s not something clients want to hear at the beginning of cooperation. Therefore, not every company includes that in the estimation, but that affects the overall cost.

How to handle that?

First, comparing different offers, check whether there is an additional amount for changes. That will help you avoid an unpleasant surprise in the future. I advise you to trust those companies that are transparent and sincere.

The second is the way you think about the project. Think about it now like a set list of requirements that you want to see working, but like a process of finding the best version of the app. You will test it with users and adjust, and test and adjust… Even when the app is launched, you will still be releasing other versions to improve it.

When the requirements change, so does the price. It’s natural. And it’s an evolution that makes Fixed-Price contracts unpredictable and unfavourable for clients. However, it might seem the opposite (you can learn why that happens in my article called 6 Fixed-Price Contract Risks and Challenges You Need to Know).

3 main elements of a reliable estimation

Now you know why estimates are so rough and inaccurate, so now the question is how to compare all the different offers you’ll get from the market.

Clearly defines what it contains

First of all, a reliable estimation is transparent. Whether it contains only the features you’ve mentioned or extend the list of software development with other, all of them are listed in the document you receive (with the time needed to build each one).

The second aspect is the definition of what was estimated. You might see an “authorisation” feature, but you should know whether that contains signing up, logging in, password recovery or login in using social accounts or mailboxes.

Even if the latter is not an essential feature for you, it might become such in the near future, and the company knows that. Some contractors might include such elements in the estimation that makes the overall timing and software development cost higher. However, it’s more than probable that such a feature will be highly required, so even if it’s not included in lower estimates you’ll have to pay for them in the end.

That also refers to the interconnected features – it should be clearly stated if the estimation contains them.

If you have doubts about what’s inside (you shouldn’t have) or why (that’s a good question), feel free to schedule a meeting with the person who made the estimation and discuss the details.

Let’s take a look at what my software development cost estimations look like. I always add a list of assessed features and a description of what should be implemented. In many cases, especially when I need clarification on the client’s goal, I prepare two versions of the estimation: a full and a stripped-down app. That allows the client to see the possibilities of software development and find their way (maybe a third one) and helps me to understand the client’s expectations.

From my experience, everything is possible. The case is what you expect to achieve and what budget you have assigned. My role is to help you to combine those two for the best result.

Variation of the estimated cost of software development

The second element of a reliable estimation is that you receive a range of costs instead of a solid value.

As you already know, it’s impossible to assess the software development costs precisely, and the estimation will undoubtedly change in the future because of changes that will be made. It is impossible to determine the costs of one particular super-custom feature, affecting the overall estimation.

A reliable partner is always transparent with that.

Complex with product consulting

Project managers and all those people who live to build digital products have an experience you can gain an advantage on. Whether you have your app live or have nothing but an idea, those people are here to advise you and help you reach the best result in software development projects.

A good estimation should be based on their experience and contain a description of what should be done, what can be improved, made simpler or with a lower cost. However, keep in mind that estimating a live app’s costs is different than building a brand-new app from scratch.

A good estimation covers all the stages of the software development process. It’s not only about building features but designing, coding, quality assurance, user testing, and then improvements after the release. Verify whether the costs of all those stages are included in the estimation. This increases the value, but those costs are inevitable, and you should be aware of that.

What to watch out for comparing estimations?

There are many pitfalls when comparing estimations you get from the market. Now, I’ll discuss the most common ones.

Start from the exact requirements

To compare offers, you need to make sure they were made based on the same information. If one company has more insight into your project, it will be able to make a better proposal in terms of what should be done, how, when, and within what budget.

Make sure you understand each other

The second case is understanding. Make sure that you and the potential contractor are on the same page and understand each other appropriately.

Even if you send documents, ensure the company knows what you mean. Feel free to catch up on a call to discuss your app idea. Every company should always be for you when you need them, and there’s no better way to get to know each other (and assess whether you want to work together) than meeting.

Check what the offers contain

The offers you’ll get vary significantly, but the difference is not meant that one company is more expensive or works longer on the same feature. They might include additional elements discussed above – money buffers, app versions, interconnected features and so on – to make the estimation more reliable.

Units of estimation

I suggest not looking at the final price (or range) but comparing hourly rates and the estimated number of hours that you got from the project manager. Below I’ll discuss both of them.

Hourly rates

Hourly rates are the ones that companies compete with each other. From my experience, if you receive an offer with a significantly higher hourly rate than all others, let them go.

However, if the values are comparable, follow your heart and choose the company that best fits you. You can schedule a call to get to know them. You should like each other. You’ll be working together! (You can read more about what to consider when hiring a software developer in Mike Popov’s article 16 Tips on How to Choose the Best Software Development Company).

Estimated hours

First of all, project managers can perfectly match their teammates to tasks they should do based on their level of expertise. There’s no point in paying for a senior developer if a middle one can successfully complete the task.

That’s important as it affects the number of hours needed to complete each task (and feature). Suppose you have a significantly different number of hours estimated for one feature in various offers that might mean that they need more time to accomplish it OR additional elements are taken into account that extends the estimation. In such a case, you should find an explanation on the offer, but it’s good to schedule a call and ask what they mean if it’s lacking.

The final words

Now you know why software development estimations are so inaccurate, and you can do your best to help contractors to prepare the best offer possible.

As usual, the devil is in the details. If you need a hand or guidance, feel free to reach me on LinkedIn.

Good luck with your app!

Lead Project Manager at TeaCode

Gabriela is a lead project manager and keeps in mind that the crucial thing in project management is always seeing the business objectives. She takes care of clients' business outcomes, and that's why clients usually give her a lot of independence.

As a web developer, she understands teammates, which is an asset in project management. UX designer background is handy when clients ask her for advice or consult their app ideas. Having this knowledge, she can address their confusedness or curiosity.

Data analysis and research have no secrets from her as she's a physicist. She knows how to discover data patterns and dependencies, which brings additional value to her everyday work.

Gabriela Jarzębska
Gabriela Jarzębska

Gabriela is a lead project manager and keeps in mind that the crucial thing in project management is always seeing the business objectives. She takes care of clients' business outcomes, and that's why clients usually give her a lot of independence. As a web developer, she understands teammates, which is an asset in project management. UX designer background is handy when clients ask her for advice or consult their app ideas. Having this knowledge, she can address their confusedness or curiosity. Data analysis and research have no secrets from her as she's a physicist. She knows how to discover data patterns and dependencies, which brings additional value to her everyday work.