How Much Does It Cost To Develop An App

You have probably spoken to a few app development companies already and the numbers you have been given are all over the place. One says sixty thousand, another says one fifty, and someone on a freelance platform has quoted you twelve. None of them are necessarily wrong, they have just each heard a different version of what you need and priced against that.

Over the years we have found that the final app development cost is almost always a reflection of how well someone understood the problem before they started quoting. 

We worked with CYSIAM, a cybersecurity consultancy whose report process was entirely manual. Consultants keying data into spreadsheets, copying it into Word documents. It worked, it was just slow and it was the obvious bottleneck to growth. The brief could easily have been “automate the reports” and we could have scoped and priced against that, but when we actually embedded ourselves with their team at there offices and walked through the whole workflow together until we found the biggest automation opportunity which was giving their clients access to upload their own data, which not only saved everyone time but also and changed what the platform needed to be. 

Then there is Catch. Catch started as a booking platform for anglers, find a fishery, book a spot. That was the app idea. But when you look at individual fisheries the numbers do not stack up commercially, there are over two thousand fisheries in the UK though and collectively that is enough to build a real business. So the product became a SaaS platform where fisheries bring their own users and those users get exposed to Catch with the ability to upsell into other services beyond bookings. The entire development cost changed because the product changed, not because features got added but because we found a better shape for the business and the app had to support that.

This is why getting a rough estimate before anyone has spent proper time with you is risky. The number might look fine on paper but if the brief is wrong the app development project is already heading somewhere it should not be going and you will not know until the budget is half spent.

These are almost always the choices around the app and the backend platform such as how complex the backend needs to be, what the user experience has to do and whether there are regulatory compliance or security requirements that the app has to adhere to.

We have used React Native on a number of projects where the client needed to be on both iOS and Android but the budget or the timeline would not stretch to building natively for each. 

One was a booking platform for a startup where we got a polished product out in under six months using a single codebase across both platforms. 

Had they gone native from the start I think the app development cost would have close to doubled and the timeline would have stretched out considerably. 

However there was a trade off and that was we ended up losing compatibility with some third party APIs that did not have React Native support at the time without going native, so there is always a conversation to have around what you gain in terms of speed to market and what you lose in flexibility when you go cross platform.

As a general rule f your app idea needs integratining with the devices hardware or platform specific features then native is usually the best option even though it costs a little more. But for a lot of the projects we see, especially early stage products where getting to market and getting user feedback quickly matters as a minimum viable product then cross platform frameworks like React Native or Flutter can save a significant chunk of the app development budget without compromising on what users actually experience.

Some of my favourites that I have been involved with have either technical complexity that we needed to solve or were in regulated industries where scale and security we equally as important and the feature set, 

I remember we built a healthcare product for parents that needed to comply with IEC 62304 which is the medical device software standard, and the AI component combined with the patient safety requirements made it more complex, took longer and cost more than a consumer app. 

On that same project there was a point towards the end of the project when we had the app in our hands that we realised the app only worked for one parent and the other parent, who was usually at work or away somewhere, had no visibility at all. So we quickly planned what secondary access could look like without a direct connection to the bluetooth device, we could with a slight delay give additional users a view on the data already synced with the servers. Whilst this was an additional feature, it ended up not being a huge amount of additional development cost, but it fundamentally changed what the product meant to the parents using it every day.

For another client, we built a social platform that had ambitions to support hundreds of thousands of simultaneous users without breaking a sweat and traditional monolith servers had obvious bottlenecks of the delay of spinning up new servers when the load is needed and dropping them again when the surge dissolves. We ended up building the project across multiple data centres using micro services, load balancing, caching and content delivery networks before submitting it to performance testing. 

Compare that to a property management app we worked on that mainly needed secure cloud storage, encryption for sensitive data and integration with third party bank APIs. Both needed careful backend development and planning around database management but the scale was completely different and the app development budget reflected that.

So what the user sees on screen is only ever part of the start of the story and what goes on behind the curtain with backend infrastructure, APIs, the logic that connects everything together is where a lions share of the money goes on most app development projects.

I learned very early on in my career that it does not matter how good the engineering is if the user experience and user interface design is wrong nobody uses it. That is actually what made me leave a software house and start an agency where great designers wanted to be and development could work together in parallel from the start.

This team worked together on a smart home device where during testing we spotted users tapping the button and nothing visibly happening on screen and a delay to the IOT device to action, so they would tap again and again. 

The physical device had a natural delay and by the time it caught up it was firing multiple times, wasting product and making people think the app was broken. The patch was simple and obvious but the issue only surfaced when we had the app in our hands, so we had to lock the button out until the first action completed. 

Mobile apps in reality are just dumb terminals and the apps need to integrated to a backend and services like payment gateways, CRM systems, Content management systems or external providers like weather or traffic data APIs.

Each of these integrations adds to the development process as we are rely on a third party system for consistency in response time and information which does not always happen,

We have found over the years though that these integrations nearly always justify the cost because they give users a great user experience and access to information across multiple system in one view port. The development cost are what they are but the real return on investment happens when the users are engaged and more of them turn up each day,

Security

On the CYSIAM project we developed to the zero trust principle, followed the OWASP Top 10 guidelines and made sure the platform would pass a penetration test before it went anywhere near their clients who were trusting them with the security posture of their entire organisation.

If the app handles personal data, sensitive data, financial information or anything health related then security cannot be something you think about at the end. It has to be in the architecture from the beginning. GDPR applies across everything and depending on the sector there are additional standards the app has to meet before it can go live. That adds to the app development cost but getting it wrong after launch is always the more expensive conversation.

The brief is always incomplete and that is fine because all we really need is the vision. The strategy, the business model, the creative, the UX and the entire development process is what we bring to complete it. Most of the clients we work with know what they want to achieve they just have not had someone in the room before who can help them see what shape the product needs to be to get there.

On most projects that means holding a series of discovery workshops, where we embed ourselves with the team and flesh out the entire strategy and scope so everyone involved understands what is going on. I find the best work comes from the gap between what the client knows about their business and what we know about building platforms, because between the two you end up somewhere neither of you would have got to alone.

I remember with CYSIAM we went through a number of wireframe iterations together to make sure all the required data was being captured, the flow made sense and that users could abandon a session and pick up where they left off without losing their progress. The entire UX was conceived up front before we wrote any code and that meant when things needed adjusting during the build, and they did because some of the data capture around their IT policy process felt clunky when we had real prototypes in front of us, those were adjustments not full rewrites.

With Catch it went further. The original brief was a booking platform, anglers find a fishery and book a spot. If we had scoped and priced against that we would have built a perfectly good booking app. 

But with the help of artificial intelligence I performed extensive market research and discovered that booking was only one part of what angers are looking for they needed a suite of tools to help them fish smarter and better, They are also a super competitive bunch and love to show off their catches. The app development project evolved into a fundamentally different thing and that only happened because we put the time in before we committed anyone’s budget.

I am a natural puzzle solver and solving challenges is whats get me out of bed each day, I place a lot of importance on the discovery phase, often over index on it and over service as its too important to shortcut. Most discovery phases range from a couple of week to a couple of months as its time well spent.

Once the discovery phase is compete and the scope locked, we move with the app development stages into UX design, mobile app development process and quality assurance which is where the majority of the app development budgetsits across most projects.

I have always preferred a hybrid approach to our development process in how we run the build where we start with a waterfall mindset of the discovery phase and then switch into agile sprints for the actual app design and mobileapp development work. This gives both our clients and the team at the agency an understanding of how long things are going to take, how much it will cost, our target users and what functions and features will entice them to stay.

The design stage with the UX and UI usually accounts for around fifteen to twenty percent of the total project, the frontend and backend development is typically fifty to sixty percent and quality assurance and testing takes up the remaining twenty to twenty five percent. Those are rough numbers and every app development project is different but it gives you a sense of where the money goes.

On testing specifically we never mark our own homework. We use an external QA agency for all of our testing because I believe the people who built something are the worst people to test it, they know how it is supposed to work and they unconsciously avoid the paths that break it. Unit testing, automated testing, integration testing and user feedback sessions with real people are all part of how we make sure the product is ready before it goes anywhere near the app stores.

I worked on a project for a national pizza food delivery brand and they wanted to launch a completely rebuilt app and launch just before Black Friday which is one of the single busiest day of the year for them. The app was almost complete but it had to been through extensive testing, so I made the call to bring in close to a hundred people across the whole company to test it with fresh eyes, different device and real world usage patterns that nobody in the build team had thought to try. 

What that final round of testing uncovered made the difference between a smooth launch with five star app stores ratings and what could easily have gone a different way. The app development cost of that additional testing round was a fraction of what a failed launch on their biggest trading day would have cost the brand.

The other thing I would say about the build phase is that transparency matters to me more than methodology. As a mobile app developer we run weekly check ins with every client so they can see exactly the projects velocity and what has been completed and what is coming next. 

This comes up in almost every conversation we have with a new client and I think it is one of the most important decisions in the whole app development process because it affects both what you spend now and what you have left to spend later.

A minimum viable product is the version of your mobile app that does enough to prove the idea works with real users without burning through the entire app development budget before you have learned anything. It is not a cheap version of the app and it is not cutting corners, it is being deliberate about what goes into the first release and what waits until you have user feedback telling you what actually matters.

I remember when we started working on a telecoms startup that wanted to disrupt the broadband market in the south west. They came to us with ambitions for a full mobile app across android and iOS with account management, service monitoring, fault reporting and a customer portal. We could have scoped and priced against all of that from day one but instead we started with market research, prototyped an MVP and designed the app around the features that their target users would actually need at launch. The rest went onto the roadmap for when the platform had real customers using it and we could make decisions based on what they were actually doing rather than what we assumed they would do.

With Catch it was similar as the first version of the platform was envisioned around proving the booking model worked. Could we get fisheries signed up, could anglers book spots, would the user engagement be there. Once we validated the market it we expanded their product with session notes, catch blueprints, social features and an entire ecosystem for anglers to improve and track their fishing. The app complexity obviously grew over time because the business has proved the right to add those new features based on what people were telling us they wanted.

The mistake I see most often is when someone tries to create a fully complete product for launch, because they are worried about launching with a product that feels incomplete and users wont like it. In reality you should never be proud of version 1 and if you are you launched too late. Its that uncomfortable feeling that drives you to make the product better in version 2 but will read world user date.

Studytracks came to me with their vision to turn the schools curriculum into songs because not all kids learn by reading textbooks and the founder knew that from experience and he had a distribution problem. We built them a mobile appconnected to a content management system backend which proved the concept, before expanding the system into a SaaS platform for schools. 

Compete was similar, a global talent competition platform that started as a user engagement platform and morphed into celebrates and brand sponsorships.

An MVP is not exclusive to startups we have also built MVPs for enterprise clients whose innovation teams needed to prove the concept internally before the board would sign off on the full app development budget. 

Getting the scope right on an MVP is not about spending less, it is about spending on the right things first and having enough budget left to respond to what you learn after launch.

This is the part that catches most new app owners off guard because the assumption is that once the app is live in the app stores the hard work is done and you can move onto the next thing. App maintenance costs need to be factored into the overall app development budget from the start.

Tasks such as bug fixing, performance monitoring, hosting, patching and keeping up with os versions is the baseline as both Apple and Google push out os versions each year and its wise to check how your app behaves on them early.

Also please do not forget about allocating budget for user support and ensuring user satisfaction with your support team.

With Catch we are still building now years later. The platform handles millions of users a year and what we work on today looks nothing like what we first launched. Session notes, blueprints, social features, tools for fisheries to manage their cashflow and how they communicate with their customers, all of that came after launch because user feedback told us what to build next and the business was set up to keep investing in the product from the beginning.

When we built Grdian it was a safety app for motorcyclists that uses all the phone’s sensors like the accelerometer, gyroscope and GPS to detect a crash scenario and then calls an ambulance unless the rider marks themselves safe. Post launch the work across different devices and real world riding conditions was just as critical as the original build because the crash detection had to work every single time on every handset we could get hold of. App performance testing on a product like that is not a nice to have, people’s lives depend on it and the ongoing maintenance and app updates reflect that.

I tell clients to set aside between fifteen and twenty five percent of the original development cost each year for ongoing maintenance and new features. Some years its mostly bug fixing and compatibility, other years its heavier when there is a platform change or the user engagement data is showing you something new needs building.

Every pound a client spends with us came from somewhere that mattered whether that is a funding round or a board budget or money they have personally put on the line. and I take that seriously, I always have because as I have been on both sides of this game as a founder myself.

If a potential client comes to me and the app development budget does not match their ambition I will also be honest and say that, try to find a solution that fits or help them find something off-the-shelf.

The flip side is also true, sometimes people come to us thinking they need to spend two hundred thousand when actually the brief just needs a bit of reshaping and the app development cost is half that 

That is what our discovery phase is or and why we put so much emphasis on it.

If you are reading this and trying to work out whether your budget is in the right place for what you want to build then the honest answer is I cannot tell you without understanding the vision first.

To give you a idea of fees of different types of app development projects and their overall development cost.

These are rough estimates based on what we have built over the years and every project is different. The only way to get an accurate quote is to have someone spend proper time with you understanding the vision first. If you are at that stage and want to have the conversation we are here for it.

If you have read all of this and you are still trying to work out where your project sits then the easiest thing to do is have a conversation. I am not going to quote you on a call, that is not how we work. But I can usually tell you within thirty minutes whether your vision and your app development budget are in the right place and if they are not I will tell you that too. No pitch, no pressure, just an honest conversation with someone who has been doing this a long time.

Let’s talk