How much does an app cost?

A daily question

Some questions you just hear over and over again. For example: Who wants some coffee? Where did you leave my car keys? Does anyone have an iPhone charger?

However, in our line of work, easily (by many country miles) the most oft asked question is this: “How much will an app cost me?”

Usually this comes with little qualification and sparse or no explanatory detail. Sometimes that really is the sole content of the email.

If you think about it, even just for a second or two (people, please think), it is an almost impossible question to answer. It’s akin to asking; ‘How good are football players?’ ‘How long does it take to walk?’ or ‘How much does a house cost?’

A two bed in Carlisle

Let’s take the house question as an example:

A simple visit to Rightmove teaches us that houses vary in cost dramatically depending on numerous factors — location, size, age and quality all play a part.

A two bed terrace in Carlisle will be considerably cheaper (starting from £50,000) than a five bed town-house in West London (from £750,000). Yet, despite your preference, they’re both houses.

Too many variables

As with houses, there are just too many variables at play to simply answer the question ‘How much does an app cost?’

Let’s take a look at a few of the main ones:

• How many features does the app have?
• What do the features do and how easily can they be built?
• Can we use external libraries to achieve any of the requirements?
• Does the app integrate with any external systems and is there a cost to them?
• What platforms or devices will it be deployed on?
• What level of customisation is the UI (user interface) going to include?
• How many native UI elements can be used?
• What level of support can we expect to get from the client?
• What external factors do we have to consider (any 3rd parties involved etc)?

Our science isn’t exact

In addition to the above variables, it’s worth noting that app development (like any software project) isn’t an exact science.

We can, and will, sometimes spend more or sometimes less time on specific areas to either ‘just do enough’ or really perfect certain features or design elements.

Of course, we always want to do the best we can, to produce an app that is as polished as possible. However, the budget allocated to a project by a client may not allow for that … and we’re ok with that.

Fixed price?

The next question that often arises is; ‘do we work to a fixed price?’

Now, this is a tricky one and different agencies and developers will approach this in different ways.

The trickiest factor is accurately estimating how long it might take to complete the project. This is not impossible, but, well… a certain analogy about string comes to mind…

Even with a tight, fixed and specific specification that considers all the aforementioned variables there are always, ALWAYS, unknown factors (risks if you will) that need to be accounted for and mitigated against in any quote or estimate, perhaps by an added percentage.

We generally advise clients not to enforce a fixed-price contract as often they will end up having to pay more than they’ve budgeted or they’ll receive a less-rounded project.

“Even with a tight, fixed and specific specification that considers all the variables there are always, ALWAYS, unknown factors”

Proposed budgets

We’re open to many options but our preferred means to deliver a project is to agree upfront with the client a ‘Proposed Budget’.

This will be based on an initial ballpark estimate from us (we’d hope to be reasonably accurate here) and an open conversation with the client regarding how much they want to spend.

From here on in, we will then work within an Agile framework to deliver the project within this budget.

We’ll work with the client to agree user stories and priorities upfront.

Then we’ll work collaboratively with the client during development to adjust and refine these, ensuring we always deliver on time and on budget.

Estimation process

It seems logical, however it’s often overlooked that we can produce the best proposal if we know your budget upfront.

It is perhaps illustrated best in a quick example;

We’re asked to build an app for a client that will remind the user to take the rubbish out (Rubbish Reminder we could call it — Trash Time already exists).

We’ll do user interviews, propose tonnes of features including; watch apps, integration with a rubbish collection API, integration with local calendars etc.

BUT… if there is only the budget to build a simple reminder app then we’ve completed missed the point. If, however, we’re told upfront there is a budget of £x then we can tailor our proposal and the associated features to match the cost.

Our process

Our process fits into four distinct phases — Discover, Define, Develop and Ongoing Development.

For the purposes of this document we’ll focus on the main ‘Discover’ process we’ll work through with our clients.

This first phase helps us to better understand your requirements and ensure that the product created has users involved and in mind right from the inception.

It usually follows the following steps:

• Firstly, gather initial information on the project and supply a basic ‘off the top of our head’ estimate, normally via phone or email. Doing this ensures we’re all roughly on the same page and avoids wasting anyone’s time
• Assuming we’re both in the same ballpark, then we’ll start to gather as much information from the client as possible. This would include a more detailed feature list, any integrations, design styles etc.
• Once we have as much information as we can possibly gather, we’ll meet internally to discuss and suggest features, additions and amendments to the client’s brief and present back to the client in a proposal document. Sometimes we’ll also produce some initial mockup designs within the proposal to help the client sell the idea internally and help people visualise what we might be able to produce.
• As part of the document we will include a proposed budget figure (or some budget options). This is the budget we propose would be appropriate for the project based on what we know. This isn’t the final figure, but it is our best estimate at this stage.
• If the client is broadly happy with the proposed budget then we’ll agree contracts, produce a statement of work and move into the Discovery Phase of the project. During this phase will will do more research, conduct workshops and work closely with the client to agree how the project will progress and if required, refine the budget to suit.

So as you can see, our process is very collaborative. It is based on both us and the client being transparent in regards to budgets and costs. It’s important to note; it’s also a process that allows the budget to be refined as we go, and adjusted if required.

Looking for an app?

We trust this article may have helped answer some of your queries and clarified the specification of your potential app.

We’d love to hear more about how we can help you — do get in touch.

Originally published at www.brightec.co.uk.