How to Accurately Estimate Software Development Costs

SOFTWARE OUTSOURCING

You’ve prob­a­bly come to this ar­ti­cle be­cause you want to know how much is costs to build cus­tom soft­ware for your busi­ness.

The short an­swer is that it will cost some­where be­tween $40,000 and $150,000 for a one mile­stone build of a soft­ware ap­pli­ca­tion.

The longer an­swer in­volves an un­der­stand­ing of what a mile­stone is and how the num­ber of re­quire­ments will im­pact the cost of the ap­pli­ca­tion.

If there’s one thing you take from this ar­ti­cle, let it be this: please do not take a list of re­quire­ments to a de­vel­op­ment agency and ask for a fixed quote.

8 times out of 10 the agency won’t give a quote; the other 2 times won’t lead to a good out­come for any­one in­volved on the pro­ject.

A list of re­quire­ments (or a 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, a ded­i­cated stage 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 what fea­tures im­pact the cost of their soft­ware ap­pli­ca­tion.

Before we dive in any deeper it’s im­por­tant to have an un­der­stand­ing of the dif­fer­ent stages that will im­pact the cost of your ap­pli­ca­tion.

The very first stage that can of­ten be de-val­ued by those that don’t have in­dus­try ex­pe­ri­ence is scop­ing. I be­lieve that we must com­mit to de­sign and scop­ing up­front to negate the risks of pro­ject fail­ures and in­ad­e­quate prod­ucts.

This then leads into the build of the ap­pli­ca­tion and fi­nally, the sup­port and main­te­nance, be­cause no soft­ware is ever ‘finished.’

Scoping

As men­tioned above, Scoping is how we can more ac­cu­rately cal­cu­late the costs of soft­ware de­vel­op­ment. Using a prob­lem state­ment that was iden­ti­fied dur­ing pre-en­gage­ment dis­cus­sions (we call this the Brief stage), we col­lec­tively cre­ate the so­lu­tion that will solve the 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).

The length of time for this process can vary but it is gen­er­ally 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­tion’s 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.

the scope process to determine cost estimates

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­er’s in­ter­pre­ta­tion of re­quire­ment X is dif­fer­ent to the clien­t’s 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 have in­creased and the de­vel­op­ment com­pany adds an ex­tra 0 to the end of the ini­tial quote.

Estimations

The first step when es­ti­mat­ing 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, fea­tures are ver­balised in meet­ings, doc­u­mented it via email, di­a­grams are drawn 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. We’ve pro­vided a more in-depth look at epics and user sto­ries here.

Once the back­log is com­plete, our de­vel­op­ers es­ti­mate based 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.

Associated with each es­ti­mate is a risk fac­tor that is com­prised of com­plex­ity and un­fa­mil­iar­ity. Requirements that are com­plex or un­fa­mil­iar are nat­u­rally riskier than sim­ple, straight­for­ward re­quire­ments. By sci­en­tif­i­cally cap­tur­ing risk and ac­count­ing for it, the es­ti­mates pro­vided carry a greater level of ac­cu­racy.

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.

Why is soft­ware de­vel­op­ment ex­pen­sive?

We’ve touched on the to­tal cost you should ex­pect, but it’s im­por­tant to un­der­stand why the costs are what they are. This will en­able you to de­ter­mine whether an agency Is good value, too ex­pen­sive or too cheap.

Yes that’s right, the alarm bells should be ring­ing if an agency is too cheap. To be­gin, let’s start with the av­er­age salary for a soft­ware de­vel­oper in Australia. Indeed AU has put this fig­ure at $92,000. That’s a good start but that num­ber is­n’t ac­cu­rate in and of it­self.

Every or­gan­i­sa­tion has over­heads like equip­ment, elec­tric­ity, rent for the of­fice space and sub­scrip­tions/​li­censes. It’s pretty rea­son­able for this to sit around 30% per em­ployee. We can’t for­get su­per­an­nu­a­tion, that’ll add an­other 9%.

Every agency needs a mar­gin. CSImarket says this fig­ure sits around the 30% mark for a pro­fes­sional ser­vices com­pany.

Our fi­nal equa­tion is $92K + ($92K x 0.3) + ($92K x 0.09) + ($92K x 0.3) = $155,480 per year = $3,300 per week (including 4 weeks leave).

How to make sure you’re get­ting the right price

Based on the cal­cu­la­tions above, we will step through and you’ll learn what a rea­son­able and un­rea­son­able weekly en­gage­ment price is.

We can’t rely on a sin­gle de­vel­oper to build an ap­pli­ca­tion them­selves. We’ll need a sec­ond de­vel­oper to en­sure the knowl­edge of the sys­tem is shared. It will also help fa­cil­i­tate cre­ative prob­lem solv­ing amongst the team.

Next, we’ll need a few other dis­ci­plines to en­sure we’re cre­at­ing an amaz­ing prod­uct. A scrum mas­ter (or pro­ject man­ager) is needed to keep the pro­ject on track, a prod­uct de­signer is needed to re­search and de­sign the best user ex­pe­ri­ence and we’ll want to oc­ca­sion­ally con­sult a cus­tomer suc­cess con­sul­tant to mon­i­tor the suc­cess of the ap­pli­ca­tion.

If one full time re­source is ap­prox­i­mately $3.3K per week then 3-4 full time re­sources gives us a range of $10K - $13K. This is your av­er­age range but de­pend­ing on the se­nior­ity of the de­vel­op­ers as­signed to your pro­ject it may be higher. Keep in mind that the av­er­age salary for a se­nior de­vel­oper is over $125,000.

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.

Ongoing soft­ware costs

As I’ve al­ready men­tioned above, soft­ware is never fin­ished. The re­al­ity is that there are costs in­volved with sup­port­ing soft­ware, just like there are costs in­volved with ser­vic­ing your car af­ter you’ve bought it.

The gen­eral rule of thumb is to bud­get 10-20% of the cost of de­vel­op­ment on sup­port.

Ongoing sup­port mod­els can fluc­tu­ate sig­nif­i­cantly from agency to agency. Some agen­cies may de­fine very strin­gent ser­vice level agree­ments (an agreed time­frame in which some­thing must be com­pleted) which leads to a higher price, while oth­ers don’t. It’s im­por­tant that you choose a sup­port model that best fits your busi­ness and prod­uct.

What I have done is I’ve cre­ated an­other ar­ti­cle that looks at some costs that are likely to be con­sis­tent no mat­ter which agency you pro­ceed with. You can read more on the on­go­ing op­er­a­tional costs of soft­ware here.

Agile Flexibility vs Waterfall

Traditionally, com­pa­nies cre­ated a sin­gle plan com­pris­ing the de­sired out­comes and strate­gies for build­ing the ap­pli­ca­tion right at the very start of a pro­ject. This is then fleshed out fur­ther to in­clude a list of re­quire­ments for this plan with an eval­u­a­tion of how long the pro­ject will take and then 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.

How does the de­ci­sion be­tween ag­ile and wa­ter­fall ef­fect bud­get?

As you might imag­ine, less flex­i­bil­ity means a greater domino ef­fect. A good ex­am­ple is the blowout be­tween IBM and the gov­ern­men­t’s 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 still wanted 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 within bud­get.

Give me the sum­mary

  • A cus­tom soft­ware ap­pli­ca­tion starts be­tween $40,000 and $150,000 de­pend­ing on the com­plex­ity and size of the app.
  • Larger ap­pli­ca­tions will cost more but should­n’t be com­pleted in a sin­gle phase.
  • Scoping is crit­i­cal to align­ing on what should be built and ac­cu­rately es­ti­mat­ing how long that will take.
  • There are on­go­ing main­te­nance costs as­so­ci­ated with soft­ware.
  • Build it­er­a­tively to mit­i­gate the risk of a pro­ject blowout.

If you want to read more on costs in­volved in soft­ware de­vel­op­ment, take a look at the 4 stages of de­vel­op­ment that im­pact costs.

Discover Software
Secrets

ABOUT THE AUTHOR

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.

How to Budget for an Agile Software Development Project

11 September 2019

What are the monthly op­er­a­tional ex­penses to bud­get for a soft­ware ap­pli­ca­tion pro­ject?

02 March 2020

The Process and Price of Software Releases

19 May 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion