In this article we’ll be discussing some of the factors behind how and when a software development company provides cost estimates and looking at some of the reasons why costs can go up as well as ways you can keep costs under control.
How much will it cost to build my application?
This has to be one of the most common questions a software development company will hear and what a great question it is! Let me start out by saying that the purpose of this article is to help you navigate the early stage of due diligence as you’re preparing to embark on your software development journey. Unless you’re in the enviable position of being fully funded, with a limitless pool of money to draw on, the first step is, naturally, to understand how much capital you might require to turn your idea or business need into a tangible, fit for purpose Application.
But back to the question; how much will it cost to build my application? Here’s the 2 words answer to that question;
Nobody knows!
At this early point in the lifecycle of your potential project there is absolutely no way of knowing that.
I’m going to say something now that you might think is a little flippant but actually really isn’t. When you’re trying to understand how much your project will cost to build, the answer is; how long is a piece of string? Let’s take a look at why that seemingly casual statement is actually true.
But before I do, let me ask you this; how much does it cost to build a house?
it’s impossible for any software developer to give you a meaningful estimate of what your Application might cost to build up front.
Even in the early stages of the project you very likely have a great idea of the broad functionality (stuff that your App can do) that you want to see in your Application. You might also have a solid understanding of your target user and you might even have done some early stage branding work to give your idea a look and feel. All of this is fantastic and will go a long way towards saving you time when you start working with a team of professional software developers. But here’s the thing, what we and virtually all development companies have experienced is how much things change once you move into the first real stage of software development; the scoping process.
During scoping, you might work with a team that looks something like this;
- a project manager – to take overall control of the journey of building your Application
- a business analyst – to help you understand how the Application might reflect your business model
- a senior developer – to make sure we can achieve what you want using currently available technology
- a UX/UI designer – to make sure your Application provides a wonderful experience and that your users can find what they want quickly
The actual make up of a scope team will vary from company to company but the good ones will cover all of the elements that I outline above. In fact, you should make a point of ensuring whomever you choose to do your work, covers all of these areas. This is best practice and is essential for a successful outcome.
Regardless of what the actual team looks like, you can bet they will have a vast amount of experience taking fantastic concepts and turning them into great products. Invariably they will come up with new ideas and ways you can achieve your goals and make suggestions that you hadn’t thought of after all, that’s their job and they do it day in, day out. During scoping, all ideas will be put on the table for consideration and that’s a positive thing, you definitely want that.
Given everything we’ve just looked at I’m sure it will not come as a great surprise you to learn that, once you spend a couple of weeks with these professionals really unpacking your concept and drilling into the details, the early stage idea you started with at the beginning of the scoping process will look quite different by the end of it.
In other words, you might have come into it thinking you were building a two story townhouse with a pool but you ended up realising you actually want a bungalow!
And this is exactly how it should be, it’s a healthy and normal part of the process of fleshing out and organically maturing your idea.
But it’s also at the foundation of why it is so very difficult to give cost estimates up front.
We truly get why this can be frustrating but you can understand why, based on this process, it would be foolish and in fact impossible for any reputable software development company to give a meaningful cost estimate before any scoping has been done and why, in fact, it does you a disservice. There is nothing more destructive to a business relationship than setting false expectations that cannot possibly be backed up in reality. After all is there really any value to you in being given a meaningless number just for the sake of it?
If someone is prepared to give you an estimate before scoping and especially if you’re looking for funding based on this number you might want to build in a buffer of +/- 80%. That’s right, the actual cost of building your application could be as much as 80% more than was indicated to you before any scoping work has been done! This is based on a well known and accepted principle called the ‘Cone of Uncertainty’ and it’s very important that you know about this especially if you’re discussing potential costs with a third party. Maybe an investor or other funding source.
Now, there are companies that will give you a pre scope estimate based on broad categorisations. For example; a small, medium or large project. But the good ones will make the cost range broad to take into consideration the Cone of Uncertainty principle. They should also make a point of explaining that any pre scoping cost estimate is very much an uncertain number.
You might think of it as a guesstimate.
One thing we would caution is to be very wary indeed of any development company that is prepared to give you a firm cost before any scoping has been undertaken. If you have already been given a quote it would be prudent and sensible to ask the service provider exactly what they based that quote on and be careful, there are plenty of rogues out there!
What about after scoping?
Once you have completed the scoping process, the situation changes completely. Now your developer has a much clearer idea of what your Application is going to look like and how difficult or easy it’s going to be to actually build it. Your idea may have been fully fleshed out or at a minimum the initial milestones of the project will be known.
To continue the house analogy, we now have a full set of plans and the fixtures and fittings have been chosen!
Only at this point can a development company give you a realistic, detailed cost estimation for your project. But – there’s always a ‘but’ isn’t there? – I would qualify that by saying even at this stage any estimate can only be based on what is known at that snapshot in time. Software development projects have a habit of changing course (sometimes multiple times) as they progress and, once again, this is a good thing. It shows that you are learning more and more about your Application as it’s becoming real and you get it into the hands of some actual users to test drive it.
On top of this there is the unavoidable reality that not every technical challenge can be foreseen at the beginning of a development build and sometimes there are surprises. To paraphrase a certain US politician; there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. A good healthy set of estimates will already incorporate a multiplyer factor for known unknowns but when a developer encounters an unknown unknown it can often mean more time (and time is money) is needed to figure out the issue than was predicted in the estimate.
The truth is, it’s an unavoidable reality of software development and we would prefer you to know that up front instead of learning it halfway through development when it’s too late. We would suggest you allow for a 10% project overrun contingency to allow for this. Worst case scenario you need it but you have allowed for it, best case you don’t and the funds can be used elsewhere in the project. Perhaps for marketing?
Have you have already gone through the scoping process? Are you wanting to validate the costs you’ve been given for a set number of weeks of development? Are you maybe wanting to check the market and get an idea of what other developers might charge for the same number of weeks? If the answer to any of these questions is yes, then we have created a simple cost comparison calculator tool that you can use to compare our costs with anyone else you might be looking at. Hopefully this can act as a useful benchmark for you.
Is there no way to know how much I will be spending before scoping is done?
Yes! By fixing the cost of the development project.
Without a doubt, the absolutely foolproof way to get an accurate up front understanding of costs is to fix them yourself! Here’s how that might work with a development company;
- have a conversation with your chosen development company and let them know what your absolute maximum budget is
- give them as much information as you can about the Application you want to build
- get them to let you know how realistic they feel your project is given the available funds
- make sure you do enough scoping, don’t try and save money here!
There’s a couple of important things to mention here. Firstly; as you move through the scoping process your team should be able to make sure you are not getting too crazy and asking for so much functionality that you will blow out your budget. In other words, it’s their job to make sure they keep an eye on how big the project is getting and keep things under control.
Secondly; as you decide what cool stuff you want your App to do, your scope team project manager should be asking you to prioritise all that cool stuff using something along the lines of;
- Must have functionality
- Should have functionality or
- Could have functionality
Why is it so important to prioritise? Because In truth even the best scope teams can’t judge exactly when they have scoped the precise amount of cool stuff to fit neatly into a set budget. But that’s ok, at the end of scoping your developer should still go through the process of estimating the time and cost to build everything that was actually scoped. If the estimate comes in above the available budget don’t panic, together with your scope team you can take functionality out – using the must have, could have and should have priority categories - until the cost matches the funds. And remember, when we talk about ‘functionality’ we really just mean stuff that your App can do.
What are the factors affecting cost?
Of course you may well not want to fix your budget up front or you might simply not want to compromise on what your App can do. If that’s the case here are some things to bear in mind:
What drives up cost? There are some common functions or Application requirements that just unavoidably take time to implement and as a result will mean more cost. When a developer hears that a client is considering any of these they will already know – and should point out to you – that this will have an effect on your budget.
Here’s a few things to look out for;
Integrations: This is when your new App needs to be connected to another existing third party App to perform a specific action or set of actions. A common example of this is payment gateways that handle payments from subscribers or users. By no means are all integrations tricky but if your App has multiple integrations the risk that one or more will prove troublesome grows exponentially. Multiple integrations can potentially cause significant cost blowouts.
Cutting edge technology: Incorporating specialised technology into your App can dramatically add cost. Apps with cool AI or machine learning are really awesome but believe me, what can look simple and seamless to us as users has not been achieved cheaply!
Hardware integration: As the Internet of Things (hardware with internet connectivity) gains real traction, there will be an up tick in the number of Apps that will want to connect with this hardware. Hardware integrations need very careful investigation to understand how they will interact with a software Application.
Desktop and native mobile Apps: Really think about whether your App needs to be available on both desktop and natively (installed on your phone) on mobile. Ask your scope team about mobile responsive web applications versus native applications. If you really want both, you’re looking at two separate codebases which will naturally add cost. It’s like building 2 houses on the same block of land instead of one.
Under Scoping: We can’t stress enough the importance of dedicating enough time and budget to scoping work. This is your chance to fully unpack and learn about the best ways your App can deliver maximum value to your users for the minimum budget spend. It is vitally important to know with as much certainty as possible what you are about to build before you start actually writing code. The last place you want to be experimenting is during the build phase of the project. This inevitably causes what’s called ‘scope creep’. Scope creep is when a client keeps adding more and more functionality into the App after the building work has started. It causes confusion and fosters inefficiencies. Our advice, don’t under cook your scoping!
So how can I keep the cost down?
Apart from making sure you’re aware of the things I just talked about, the best way to keep your initial cost to a minimum is to start small and enhance your App over time. Pick a single compelling problem that you want to solve for your users with your new App and just build a solution for that. This approach is called the Minimum Viable Product or MVP approach. You might have seen this acronym or heard people talk about it.
You don’t need to create the ultimate all singing all dancing App with your first development release. In fact, it is arguably much more beneficial to start with a simple App, release it, learn what your users think about it, then add more functionality and re-release based on that feedback. This cycle is called the Build, Measure, Learn cycle and can lead to a much better fit between what your users want and what you give them. This is often called the Product/Market Fit and you should be laser focused on it.
To help you understand how to think about minimum viable product (MVP) Apps, let’s summarise what an MVP is and what it isn’t:
MVP is:
- Designed to drive change - by experimenting with new ideas
- Created to solve a real problem – gets your target users interested
- There to generate user feedback – so you can use it to drive the next iteration of your App
- Smaller than you might expect – doesn’t require a large budget to learn from your users
MVP is not:
- A profit generator – it’s a learning opportunity
- Meant to wow your users – it’s about solving a single problem
- The finished product – it’s just the first stage of your new business
- Set in stone – it is supposed to change according to feedback
Think of it as a layer cake. We’re starting with the base in a flavour we believe everyone will like then we ask our users what other flavours they want to see in the next two layers of the cake. By measuring those responses we can create the next layer based on what the majority wants (remember product/market fit?). Then we repeat this process until we have a whole cake and only then do we put the icing and finally the cherry on top!
So, as you can see, there are many ways to slice the cake when it comes to building an Application and I hope this has been a useful read. Are you surprised by anything you’ve learned in this article? There is much more than meets the eye when it comes to understanding how much a new Application, built from scratch, might cost isn’t there? I hope my ‘building a house’ analogy now makes a little more sense! It’s just one way of thinking about software development but it fairly accurately reflects why many, if not most, professional software development companies just can’t give accurate estimations before scoping.
About the Author
Blair Williams is the Head of Growth at Geekseat. Located in our Brisbane, Australia office, Blair has 5 years of experience in software development sales and is keen on making the software development process as smooth and predictable as possible for all.