7 hidden app development costs you should avoid

published in Business
by Arthur Krupa

Cutting corners isn’t always easy, especially when you want to maintain decent quality. Even with a perfect cost estimate, there is plenty of room for unplanned expenses that can ruin your finances. The following article will show you how to avoid them during iOS, Android or Windows Phone app development.

TL;DR: The most important factors we’ve found for increasing app development costs are:

  1. Technology that doesn’t fit product lifespan
  2. Uninformed platform support
  3. The wrong financing model
  4. Forgotten post-launch costs
  5. Third-party integrations
  6. Design miscommunication
  7. Low client involvement

1. Technology that doesn’t fit product lifespan

When you think about the app development costs, there are several things that come to mind: developer salaries and an availability, quality of platform tools (e.g. programming IDEs, SDKs), community support (like stack exchange), running costs (servers, licenses).

These are all important factors, but their assessment is always subject to a personal opinion. A die-hard .NET developer will tend to praise Microsoft’s high quality ecosystem, as opposed to a Linux admin who prefers freedom of choice and independence. They all have their merits, but we won’t go into the detail.

When you look at a product’s lifespan, it’s all about prioritizing feature development speed vs. maintenance convenience. Do you need a simple tool to be used by a small team for a limited time? You probably prioritize features over a maintenance, so a JavaScript web app will work just fine and be easy on your budget.

Do you plan to expand features, support lots of users and perform demanding operations under a heavy load? Maintenance and scalability get pretty challenging when dealing with sensitive matters (e.g. finances, manufacturing) or a large user base. You might consider more robust technologies like .NET, which are surrounded by a mature ecosystem and a large community.

In the mobile realm, the decision generally boils down to native vs. hybrid programming. Each platform has its own native set of programming languages, frameworks and software tools. They enable developers to take full advantage of a phone’s capabilities.

With mobile apps, product lifespan is the most important factor. Does your mobile app need to be a scalable entry-point for a growing service? Or is it just a companion for a one-time event or campaign?

In some cases, creating a ‘one-for-all’ hybrid mobile app can be more than sufficient (using frameworks like Ionic, Kendo UI or Mobile Angular UI). Development gets reduced to one ‘mother-app’ which is then automatically converted to different platforms. These technologies are perfect for apps with a short lifespan and limited functionality but fall short of native apps when working with multimedia or phone sensors.

2. Not Knowing your target’s key platforms

So you want your product to be accessible by everyone. Why should we leave out parts of our market share, if we can support as many platforms as possible, right?

Not entirely. An all-inclusive approach is certainly great but it is also very expensive to maintain and, in most cases, not worth the effort. For instance, developing a Windows Phone app for UK-based users can be reasonable, but should be reconsidered when targeting the US, where WP market share is dwindling to below 3% (Q1 2016, Kantar Worldpanel).

When developing an Android app, you have to look closely at your target’s device statistics. Although Google provides major OS upgrades every two years or so, the vast majority of device manufacturers stays way behind with their Android spin-offs.

This leads to a situation in which we have an almost 3-year-old system making up a third of Androids global market share (Q1 2016, Android Dashboard). Providing backward compatibility for version 4.4 (KitKat) and Lollipop (5.0) means that whole pieces of the software have to be written separately, in order to work with different APIs and support libraries. Even implementing Google’s Material Design requires a lot more effort, while still leaving much to be desired.

Apart from phones, we have a whole separated category of tablets, phablets, smartwatches, smartTVs and embedded devices, which all require much more than just UI adjustments. OS producers currently provide many incentives for app-owners to support these new platforms, as their market adoption is still very slow.

Much of the hassle is spared when creating web apps, although there are different things to take into consideration. Browsers use different engines for rendering websites, which may cause inconsistencies is some cases. This isn’t a major problem if you leave out everything older than Internet Explorer 11.

Another factor are the devices themselves. As mobile web usage surpasses desktop, responsive web design (RWD) is basically a must. This has to include not only self-adjusting layouts, but also supporting different pixel densities (like for the Apple’s Retina screens) and input modes (touch, mouse, keyboard, voice), not to mention accessibility features (try to ask a 50+ year old how he feels about reading 10pt text).

3. Low risk always comes at a price

Depending on your preferred financing model, risk is an enormous factor when calculating costs. At first glance, a fixed price model might seem the safest choice (in contrast to a time & materials model): you agree to get your app delivered for a certain price and your budget stays safe, right?

The problem is, the price isn’t the only thing that gets fixed: every unexpected change means extra costs. It’s a very big problem with Agile PLM, where change management and constant budget negotiations eat up a lot of time. You can read more on how fixed pricing can paralyze an Agile SCRUM workflow in this article.

A fixed-price contract shifts most or all risks from the consumer to the supplier, which means the price gets inflated very easily. By adding management costs and risk margins to initial estimates, the final price of change requests can easily get higher by 50% than in a time & materials model.

4. The first release is just the beginning

After launching, your running costs won’t be reduced to the server fees. A software lifecycle doesn’t have an end-date and has to include regular maintenance and updates. Even if you don’t want new features, your app doesn’t run in an isolated ecosystem and has to be constantly adapted to a changing environment: bug reports, web browser inconsistencies, system updates, security vulnerabilities etc. Not convinced that an outdated website image plugin can pose a security threat to your company? Mossack-Fonseca wasn’t either.

Apps have to be tested pro-actively to keep up with significant changes in the ecosystem (e.g. a new iOS release or flagship phone). Additionally, you will receive bug reports from users, mostly imprecise and poorly described. How to deal with them while getting the most out of it is a separate subject.

App development costs

Source: sd.keepcalm-o-matic.co.uk

5. Being too optimistic about 3rd party tools

When planning your product, you’ll probably consider using existing SaaS solutions to scale your app’s functionalities (like online payments, analytics, testing etc.). What marketing slogans won’t tell you is that out-of-the-box doesn’t always mean “easy to implement”. Aside from licensing costs, each solution will always require a certain amount of planning, development and testing.

When deciding, always see how well a product is documented (it’s API, libraries etc.) and for how long it’s been around. Building your core functionality around immature 3rd party solutions is very risky and should be avoided in early releases.

A separate case is when your app has to be integrated with a closed system, where you can’t rely on existing documentation our community support. SaaS solutions targeted to a large market have to be well-documented in order to sell, but niche- and monopoly-based solutions don’t (e.g. carrier billing systems or government-owned services).

In such a scenario, the majority of knowledge will eventually have to come from external developers and managers, which means you’re completely dependent on their schedule. Any time estimates for integration with closed systems are basically unpredictable.

6. Design isn’t understood clearly

Until recently, UI design used to be commissioned separately to freelancers or UX/UI agencies. Although the trend is shifting towards having a designer close to the development team, both approaches can work well if communication is effective. The more designers and developers understand each other, the faster they find solutions.

When working with a separate design team, make sure they provide very specific instructions for your developers (e.g. a documentation with general style guides and detailed specs of each interface screen). Vague descriptions or even lack thereof will always result in inconsistencies and new requests to the designers. It’s not the developer’s job to fill out the blanks, so if something isn’t implicitly specified, it will probably get skipped or replaced with the first thing at hand.

If it just happens, that UX and UI experts are an integral part of the development team, design specs can be a lot leaner. With an in-house designer, developers can ask questions directly and get immediate solutions, without the hassle of updating specs. It can be a bit disruptive, but it the long run it saves a lot of time. Furthermore, such an approach fits perfectly into the lean methodologies, where changes can be frequent and unpredictable.

7. The dev team is always one step ahead

Although a pro-active attitude is usually very welcome in business, it isn’t always productive. It’s ok when it happens in advance (during planning) or if it serves as a quick fix. But it should never involve guessing too much.

Imagine you have a tight schedule for a feature, but the documentation has still some holes in it. To some level, it is possible to work around a problem, but it often goes too far. If a feature is requested but not entirely specified, somebody else will have to work out the details for you (usually without seeing the whole picture).

A very common scenario is when the project specification is ready but the UX isn’t. The dev team wants to do their job, so they draft out the interface on their own. Once the UX documentation arrives, it occurs, that the devs used the wrong interface controls, assumed a different view structure and didn’t include some important information in database queries. Fixing falsely made assumptions can seriously burn your budget.

The Parable of the Blind, by P. Brueghel

The Parable of the Blind, by P. Brueghel (source: en.wikipedia.org)

Summary: How to avoid hidden app development costs

  1. Choose technologies that fit your project lifecycle and always try to get a second opinion to avoid biased recommendations.
  2. Get to know your userbase and remember about the bell curve when deciding on platform support.
  3. When working with Agile PLM, be ready for changes.
  4. Plan at least 20% of your budget for post-launch costs.
  5. Don’t be overly optimistic with 3rd party solutions.
  6. Facilitate communication between designers and developers.
  7. Be there. You are a key figure in the team, remember that.

Check out other business articles on our blog.

Arthur Krupa CDO, founder

Designer by profession, and an engineer at heart. At Zaven he supervises everything connected with visual communication and user experience. On quiet evenings, he enjoys watching documentaries, playing the piano or reading a book. Arthur has a passion for trekking and climbing, that’s why he catches himself daydreaming about mountains far far away...

Popular posts




Read more
How to overcame the fear of hiring outsourced developers?

How to overcame the fear of hiring outsourced developers?


Read more



Read more
Mobile Apps

Get your mobile app in 3 easy steps!


Spec out

with the help of our
business analyst



design, implement
and test, repeat!



get your app out
to the stores

Contact us

Estimate app cost!

back to top