How Much Does It Cost To Develop A Mobile App? – Fixed-price vs T&M

As far as I know, everyone likes to know upfront how much they are going to pay for something. I do anyway. When I buy a new TV, I want to know what sort of a sum I will be parting with. Same with paying someone to fix my dishwasher (you try to explain to 2-year old plasticine don’t go in it).

Get what you pay for

As much as the TV is fairly easy to put a price tag on, when it comes to putting a price on a service it’s more like “I will tell you when I see what needs doing”. Man, that plasticine got near damn everywhere.

We’re in the business of making software. Web and mobile apps development, UIs, UXs is what we breathe. What we do for you is much more like fixing your dishwasher than selling you a TV set. Weeell.. maybe more like fixing your dirty dishes problem by designing and developing a tailor-made piece of equipment that will forever change the way you approach housekeeping 🙂

Pay for what you get

Mobile app price depends on many different factors, so it’s not so easy to say that the cost of creating Uber like application will be $XXXX.  Pricing of your project depends on your requirements, not specification of existing products like Uber.

There are two most popular ways to price software development. Fixed price – a pre-set sum for the entire development, and T&M (time and materials) – the actual usage cost based on loaded hourly rates.

To become familiar with the application development process we recommend to read our previous article – Android and iOS app development life cycle.

How to price an app? – All the sins of fixed-price

The risk factor

In essence, each of the 2 pricing models faces different risks. Those risks are differently managed for a rigid fixed-price and more flexible T&M model.
When you pay a fixed price for developing a mobile app, your project will most likely need to be split into two phases. In order to define requirements and scope of the project in detail, a full Product Discovery is done before development. This allows to identify all the risks and plan for those in advance.

The consequences of this is obvious longer project duration. For developers, the rigid nature of fixed-price means more complex administrative processes and very careful overhead estimations to both cover the risks and remain competitive.

For you, the main risks stem out of the rigidity of the contract and resistance to introducing changes during development. In fixed-price model all crucial decisions must be made in the earliest stages of the project. During proper development, each change will require renegotiation of scope and price, possibly moving the deadline as well.

The flexibility of T&M allows to start development phase much quicker, based on less defined and set scope. Single phase project progresses faster, changes and adjustments are easier to introduce, risks managed as they arise.

More on change in Agile Scrum software development is available in our Product Owners Guide to Agile Scrum Part 1

Paying for actual work (man-hours) done on your project, reduces the need for overheads, which in turn lowers the loading on hourly rate. Invoices are usually issued at the end of an iteration (eg. a Sprint in Agile Scrum management) and contain only the actual hours worked.

Agile project management does require more involvement on your side. Accepting and adjustments, feedback and changes will need to be continuously communicated to ensure the product meets your expectations and development time is utilized to maximum efficiency.

If it don’t fit…

In the business of software development, the risks are plenty. Technology zips forward faster than anyone’s ability to keep up, new technologies, new devices, new possibilities come up every day. We do our best to 1. Keep up and remain relevant 2. Not take on tasks that are outside of our skill set or capabilities. This is how we’re different to many industry hopefuls, grabbing on any and all opportunity to make money without really considering if they are the best fit for the task or if the task is a good fit for them.

The real risks

This is how we manage the known risks. What about the unknown? The most common issues that come up during mobile software development is the third party involvement. As a client, you give us a set of tasks, deadlines, and requirements to fulfill. With this, we have no issue at all. Once you start talking about delivering your own pieces (like the backend, APIs, 3rd party SDK, external databases, services) to integrate your software with, now this is where we start walking on a minefield. Take an API for example. You could be giving us something that was written years ago in technologies since forgotten or simply not capable of supporting functionalities we are building into your new mobile application.

You stop, we stop

Can’t possibly put a price on that. Or when you have your own team of developers writing your backend (server) side of the application. We have no guarantees on them doing the job on time, doing it right, or according to requirements. A week of their delay means the same for us, and we are still paying our guys for every day where they can’t effectively do any work. In a fixed price model – that’s our money going down the drain, because of the issues you are creating.  

Rigid and flexible don’t mix

Fixed-price, so basically establishing at the start of our business relationship how much we are going to charge you for our services, as attractive and defined as it may sound, is not a realistic option.

In the beginning, everything looks fine. The requirements are thoroughly defined, the scope clear, documentation complete, everyone knows what they’re supposed to do. So we agree on the price and start working.

A couple of weeks into the project, you come to us with a new idea for your software. A little extra feature that will look good in your mobile app. Out the window goes the set of requirements, the scope, and the relevance of the documentation. Small feature for you, a big job for us.

Your fixed price doesn’t look so fixed anymore. Now we need to sit down again, reevaluate the whole project, find savings by cutting some stuff that’s not crucial and hasn’t been made yet, and so on and so forth. The process itself is expensive already, and we didn’t even start working on your “little extra feature”.

Agile is that agile does

In real life, it gets more complicated than that. Developing mobile and web apps is a process of constant adjustments, changes, and improvements. We need to work with you, not just for you. If you’re serious about the quality and the best end result achievable, you will need to give us some options.

Agile software development, eg. in Scrum methodology – by definition assumes flexibility, openness to change and constant adjustments. And that’s change and adjustments coming from your (client’s) side mostly. Fixed-price introduces rigidity to the process, which plainly goes against the idea of agility. A set price looks good on paper, but once the mobile development is in full swing, the lack of flexibility in one area causes issues in others, like altering the specifications of your product during development. The fixed-price for mobile app we gave you was for exactly the set of requirements you provided. Any alterations, new additions or changes of direction are not facilitated and require additional contracts (change agreements) to be drafted.

An estimate is not a price

No estimate is ever perfect. In the fixed-price model, the room for error and unforeseen circumstances are dealt with by introducing hefty overheads. And the reality is, in your fixed-price estimate, you will not find the word “overhead” anywhere. So even if everything goes smooth, and the said overhead is never used, well.. you said bye-bye to that money already and it most likely went straight into the new Rolex of the guy you paid it to.

So, we estimate our software services in a Time & Materials model. The breakdown into hours of particular specialists actual work will show you how long each of the phases/parts of your product’s development should take. We will be estimating the scope that we discuss with you at length and as thoroughly as possible. Basically, the more we learn about your needs, the closer our estimate will be to the final price you will pay.

In this model neither you learn the final price for your mobile or web app, nor do we find out exactly how long it’s really going to take to develop it. Not straight away. It’s called development for a reason… The clarity of the vision and the complete picture of the end result (and the price) become more defined when the process is actually taking place.

Get the pros to estimate the cost your mobile app

The more professional and experienced the mobile developer is at their job, the more accurate his initial estimate of mobile app development cost will be. The best ones out there usually would have been in the market for several (5+) years with a portfolio of 100+ projects and a few big names among their clients.

When estimating a development in T&M, we take all your requirements, propose our solutions, compare with our past projects and put together an estimate providing a number of hours it should take our dedicated development team to develop your app. Your estimated price is the said number of hours multiplied by our current rates. As much as the rates vary between developers (usually along with the level of delivered quality), the general amount of hours should be roughly within the same range.

Keep that in mind when comparing estimates from several developers. If 3 of them give you an estimate for around 900 hours (mid-size project) and one clocks it down to 600 and another up to 1100, then it’s pretty much a no-brainer.

When you come to us with your idea for a mobile or web app, software or other IT services we do our best to estimate accurately how much your project will cost. The accuracy of our estimate is just as important to us as it is to you. As software developers, we are judged through the prism of quality, price, and the ability to deliver. As in all things business, the one thing that’s hardest to come by is trust. To consider something else than a fixed-price for our services you will need to be convinced, or at least have some guarantee that it doesn’t mean simply writing us out a check in Blanco.

Fair for everyone

T&M is the one billing model all software developers love. The main reason being it’s fair to both sides. There’s no magic AI gizmo we feed instructions to (or maybe there is… you will never know) and it spits out a shiny new piece of software you want. Each piece of code, graphic design, UI, analysis etc. take our developers time to do. I think it’s only fair to be paid for the work you do for someone. T&M billing comprises only the actual hours worked on your project, so you will never pay for something that hasn’t actually been done. This gives you better control over budgeting and enables ongoing adjustments, alterations, and changes of direction in your development. Every invoice has the breakdown of the hours of work performed on your project and can (and should) be checked against time tracking reports of your team. This gives much higher transparency and accountability than fixed-price billing, which is simply paying off an installment of the whole sum.

To consider something else than a fixed-price for our services you will need to be convinced you’re working with the right people. The judgment I will leave to you, with a small tip: Never trust a man who says you can trust him.