How to Accurately Estimate Software Development Costs

The over­all ef­fect on the soft­ware in­dus­try for this type of cost­ing is neg­a­tive. Projects fail due to in­ad­e­quate scop­ing, or soft­ware is built be­low par be­cause the soft­ware de­vel­op­ment ven­dor does not truly un­der­stand their craft.

If you can’t de­scribe what you are do­ing as a process, you don’t know what you’re do­ing.” - W. Edwards Deming

I be­lieve that we must com­mit to more de­sign and scop­ing up front to negate this prob­lem. A list of re­quire­ments or vi­sion for the pro­ject can be in­ter­preted many ways. It is crit­i­cal to align the stake­hold­ers in­volved in the soft­ware pro­ject be­fore set­ting ex­pec­ta­tions around time and bud­get. WorkingMouse does this through our Way of Working. Specifically, the scop­ing stage is de­signed to align stake­hold­ers, cre­ate a well doc­u­mented back­log and a click­able pro­to­type so that our de­vel­op­ers un­der­stand ex­actly what it is they are build­ing. This al­lows us to sci­en­tif­i­cally es­ti­mate on the re­quire­ments and com­mu­ni­cate to clients how much it will cost to build their soft­ware ap­pli­ca­tion.


As men­tioned above, Scoping is how we can cal­cu­late the costs of soft­ware de­vel­op­ment. Using the prob­lem state­ment that was iden­ti­fied with the client in the ear­lier Brief stage, we iden­tify the so­lu­tion that is needed to solve that prob­lem. To find the so­lu­tion we move in se­quence through the dis­cov­ery, in­spi­ra­tion, ideation and re­al­i­sa­tion stages (see di­a­gram be­low).

This process can vary be­tween 2 and 4 weeks. Importantly, at the end of scope we emerge with a num­ber of de­liv­er­ables in­clud­ing;

  • A click­able pro­to­type of your soft­ware that can be tested and val­i­dated,
  • Requirements back­log with im­ple­men­ta­tion steps,
  • Your ap­pli­ca­tions schema,
  • Roadmap, and,
  • A cost break­down of each piece of func­tion­al­ity.

See our soft­ware pric­ing guide for our step by step price break­down.


What to avoid when look­ing for costs

The trap that many soft­ware de­vel­op­ment com­pa­nies fall into is giv­ing a quote be­fore ad­e­quately scop­ing a pro­ject. This is in­cred­i­bly prob­lem­atic when the pro­ject is in the midst of de­vel­op­ment and it be­comes clear that the de­vel­op­ers in­ter­pre­ta­tion of re­quire­ment X is dif­fer­ent to the clients in­ter­pre­ta­tion of re­quire­ment X. Now, the com­plex­ity of the pro­ject has in­creased and the de­vel­op­ment com­pany adds an ex­tra 0 to the end of the ini­tial quote.

The other likely pit­fall is that a pro­ject may ini­tially con­sist of 20 re­quire­ments. But in the midst of de­vel­op­ment the client re­alises that an­other 10 re­quire­ments are ac­tu­ally needed to sat­isfy the var­i­ous user groups. We call this scope creep. Without ad­e­quate time to plan and align on the di­rec­tion of the soft­ware, it will in­evitably suf­fer from scope creep. Now, you’re back in the same po­si­tion as above. The scope and com­plex­ity has in­creased and the de­vel­op­ment com­pany adds an ex­tra 0 to the end of the ini­tial quote.


The first step when es­ti­mat­ing on a pro­ject is to cap­ture the re­quire­ments. There are many ways for pro­ject own­ers to ex­press the in­tent of their soft­ware. Typically to de­scribe the soft­ware, they ver­balise it in meet­ings, doc­u­ment it via email, draw di­a­grams on a white­board, etc. The aim of these strate­gies is to achieve a shared un­der­stand­ing of what needs to be built. Capturing these re­quire­ments ac­cu­rately is im­por­tant for min­imis­ing the risk of flawed it­er­a­tion es­ti­mates.

Our strat­egy for cap­tur­ing these re­quire­ments is to un­der­stand the user in­tent through Epics and User Stories.

An epic is a de­scrip­tion of a coarse-grained re­quire­ment in a story form. It may rep­re­sent a theme, which can be used to cat­e­gorise a bunch of re­lated User Stories.

A user story is a de­scrip­tion of a fine-grained re­quire­ment. Each user story be­longs to ex­actly one epic, where the user story is a sub­set of the fea­ture de­fined by the epic. A user story is the unit of de­liv­ery for Iterations, so by de­f­i­n­i­tion a user story must be suf­fi­ciently small to de­liver in a sin­gle Iteration. For a more in depth look at epics and user sto­ries visit this blog.

Once the back­log is com­plete, our de­vel­op­ers es­ti­mate on each of the user sto­ries iden­ti­fied. Our time es­ti­ma­tion fol­lows a pre­cise, ex­po­nen­tial scale:

  • 1 hour (0.13 days*)
  • 2 hours (0.26 days*)
  • 4 hours (0.52 days*)
  • 8 hours (1.05 days*)

You might be won­der­ing, why can’t some­thing be 3 hours or 6 hours of work? Why does it have to in­crease ex­po­nen­tially? The ra­tio­nale is that the big­ger some­thing is, the less pre­cise we can be on how long it will take. We can say that paint­ing a room will take 2 hours, that tiling floors will take a day but we would­n’t say that build­ing a house will take 4 months, 2 weeks, 3 days and 1 hour.

This es­ti­ma­tions process en­ables WorkingMouse to more ac­cu­rately cap­ture re­al­is­tic es­ti­ma­tions of the cost of de­vel­op­ing soft­ware.

Agile Processes

From here the es­ti­mate can be­come more ac­cu­rate if the de­vel­op­ers work with an Agile method­ol­ogy. Breaking down the pric­ing into sprints al­lows for cost­ing to be as­sessed per it­er­a­tion rather than a rough over­all fig­ure.

Traditionally, com­pa­nies work with one big plan which they cre­ate by de­vel­op­ing a strat­egy, op­er­a­tion and tac­tic from the start. They come up with a list of re­quire­ments for this plan, eval­u­ate how long the pro­ject will take and then pro­vide a cost es­ti­mate. This is called wa­ter­fall de­vel­op­ment. The down­side to this strat­egy is that the feed­back and learn­ing process is­n’t avail­able un­til you’ve al­ready fin­ished de­vel­op­ment.

One ex­am­ple of this is the mas­sive blowout that hap­pened con­cern­ing the gov­ern­ment con­tract with IBM to de­velop a health pay­roll sys­tem. The pro­ject was con­tracted to IBM in 2007 but was plagued by de­lays and bud­get blowouts. When the re­lease fi­nally hap­pened, the sys­tem failed, re­sult­ing in a com­plete scrap­ping of the pro­ject. However, IBM was still want­ing the full pay­ment of around $1.2 bil­lion. This fail­ure can be linked to de­vel­op­ing with­out ef­fec­tive scop­ing and build­ing with­out test­ing.

Working in it­er­a­tions al­lows you to build to smaller tar­gets. At the end of each tar­get you can ob­tain valu­able feed­back to as­sess if you are still work­ing to­wards the right pro­ject goals. This pro­vides huge cost sav­ings as you pick up changes that need to be made at a much ear­lier stage in the build. This pre­vents sit­u­a­tions like above, where clients are not aware of is­sues un­til the fi­nal prod­uct is re­leased and the fi­nal pay­ment is due. For ex­am­ple, if you have a plan to de­velop a pro­ject in 3 sprints and through feed­back iden­ti­fied changes to the re­quire­ments af­ter the first it­er­a­tion, then you could save on the fi­nal two thirds of the cost by pick­ing up on the is­sue ear­lier. For this rea­son the ag­ile method­ol­ogy can help to de­liver suc­cess­ful pro­jects on time and bud­get.

Developer Costs

It is rel­e­vant to note the cost of de­vel­op­ers re­quired for a pro­ject. This fig­ure is then used in com­bi­na­tion with the cost of the sprints and mul­ti­plied out. However, this is the part of the process that has the great­est im­pact on the over­all pro­ject cost. Generally in Australia the av­er­age soft­ware de­vel­oper salary is over $83 000 per year. Additionally, soft­ware ar­chi­tects and se­nior de­vel­op­ers can earn on av­er­age over $120 000 and up to $176 000 per year. These fig­ures can per­suade busi­nesses to turn to off­shore soft­ware de­vel­op­ment.

Offshore soft­ware out­sourc­ing can ap­pear a much cheaper al­ter­na­tive be­cause of the lower wages af­forded to over­seas de­vel­op­ers in coun­tries like India. However, off­shore out­sourc­ing comes with a va­ri­ety of long term risks and may in­volve un­ex­pected costs such as le­gal fees or ad­di­tional train­ing costs. In fact one of our pre­vi­ous ar­ti­cles about the 20 risks as­so­ci­ated with out­sourc­ing off­shore’ noted that fig­ures sug­gest the fi­nal sum up of off­shore de­vel­op­ment can leave ex­pen­di­ture up to 65% higher than es­ti­mated.

Alternatively, WorkingMouse uses Codebots to help max­imise the ef­fi­ciency of our on­shore de­vel­op­ers. These are soft­ware bots that are able to write more than 90% of an ap­pli­ca­tions code, which max­imises the ef­fi­ciency of our de­vel­op­ers and testers. We be­lieve that this helps re­duce the over­all cost of pro­jects and de­liv­ers more value to clients. It also helps keep work on­shore.

Using these strate­gies to re­fine the cost­ing process for build­ing soft­ware will greatly help to­wards achiev­ing a more ac­cu­rate es­ti­mate. Reducing un­ex­pected costs can in turn help main­tain a bet­ter cus­tomer sat­is­fac­tion level and so is ben­e­fi­cial to both the soft­ware de­vel­op­ers and cus­tomers. More im­por­tantly though, im­ple­ment­ing a thor­ough scop­ing process will lead to a higher chance of cre­at­ing suc­cess­ful soft­ware.

If you want to read more on out­sourc­ing, check out David’s ar­ti­cle on how you can pro­tect your IP when out­sourc­ing in India.


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call