1. Technology that doesn\u2019t fit product lifespan<\/h2>\n
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).<\/p>\n
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\u2019s high quality ecosystem, as opposed to a Linux admin who prefers freedom of choice and independence. They all have their merits, but we won\u2019t go into the detail.<\/p>\n
When you look at a product\u2019s lifespan, it\u2019s all about prioritizing feature development speed vs. maintenance convenience. <\/strong>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.<\/p>\n 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.<\/p>\n 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\u2019s capabilities.<\/p>\n 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?<\/p>\n In some cases, creating a \u2018one-for-all\u2019 hybrid mobile app<\/a> can be more than sufficient (using frameworks like Ionic<\/a>, Kendo UI<\/a> or Mobile Angular UI<\/a>). Development gets reduced to one \u2018mother-app\u2019 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.<\/p>\n 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?<\/p>\n 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.<\/strong> 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, <\/span>Kantar Worldpanel<\/a>).<\/span><\/p>\n When developing an Android app, you have to look closely at your target\u2019s 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.<\/p>\n 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<\/a>). 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\u00a0different APIs and support libraries. Even implementing Google\u2019s Material Design<\/a> requires a lot more effort, while still leaving much to be desired.<\/p>\n 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.<\/p>\n Much of the hassle is spared when creating web apps<\/strong>, 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\u2019t a major problem if you leave out everything older than Internet Explorer 11.<\/p>\n Another factor are the devices themselves. As mobile web usage surpasses\u00a0desktop, responsive web design<\/em>\u00a0(RWD) is basically a must. This has to include not only self-adjusting layouts, but also supporting different pixel densities (like for the Apple\u2019s 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).<\/p>\n Depending on your preferred financing model, risk is an enormous factor when calculating costs. At first glance, a fixed price<\/em> model might seem the safest choice (in contrast to\u00a0a time & materials<\/em> model): you agree to get your app delivered for a certain price and your budget stays safe, right?<\/p>\n The problem is, the price isn\u2019t the only thing that gets fixed: every unexpected change means extra costs. It\u2019s a very big problem with Agile PLM<\/abbr>, where change management and constant budget negotiations eat up a lot of time. You can read more on how <\/strong>fixed pricing <\/strong>can paralyze an\u00a0<\/strong>Agile SCRUM <\/strong>workflow <\/strong>in this<\/a> article.<\/p>\n A <\/strong>fixed-price <\/strong>contract shifts most or all risks from the consumer to the supplier<\/strong>, 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<\/em> model.<\/p>\n After launching, your running costs won\u2019t be reduced to the server fees. A software lifecycle doesn\u2019t have an end-date and has to include regular maintenance and updates. Even if you don\u2019t want new features, your app doesn\u2019t 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\u00a0an outdated website image plugin can pose a security threat to your company? Mossack-Fonseca<\/a> wasn’t either.<\/p>\n Apps have to be tested pro-actively to keep up with significant changes in the ecosystem<\/strong> (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.<\/p>\n Source: sd.keepcalm-o-matic.co.uk<\/p><\/div>\n When planning your product, you\u2019ll probably consider using existing SaaS<\/a> solutions to scale your app\u2019s functionalities (like online payments, analytics, testing etc.). What marketing slogans won\u2019t tell you is that out-of-the-box doesn\u2019t always mean \u201ceasy to implement\u201d<\/strong>. Aside from licensing costs, each solution will always require a certain amount of planning, development and testing.<\/p>\n When deciding, always see how well a product is documented (it\u2019s API, libraries etc.) and for how long it\u2019s been around. Building your core functionality around immature 3rd<\/sup> party solutions is very risky and should be avoided in early releases.<\/p>\n A separate case is when your app has to be integrated with a closed system, where you can\u2019t 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\u2019t (e.g. carrier billing systems or government-owned services).<\/p>\n In such a scenario, the majority of knowledge will eventually have to come from external developers and managers, which means you\u2019re completely dependent on their schedule. Any time estimates for integration with closed systems are basically unpredictable<\/strong>.<\/p>\n 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.<\/strong><\/p>\n 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<\/a> 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\u2019s not the developer\u2019s job to fill out the blanks, so if something isn\u2019t implicitly specified, it will probably get skipped or replaced with the first thing at hand.<\/p>\n 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.<\/p>\n Although a pro-active attitude is usually very welcome in business, it isn\u2019t always productive. It\u2019s ok when it happens in advance (during planning) or if it serves as a quick fix. But it should never involve guessing too much.<\/p>\n 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).<\/p>\n A very common scenario is when the project specification is ready but the UX isn\u2019t. 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\u2019t include some important information in database queries. Fixing falsely made assumptions can seriously burn your budget.<\/strong><\/p>\n The Parable of the Blind, by P. Brueghel (source: en.wikipedia.org)<\/p><\/div>\n2. Not Knowing your target\u2019s key platforms<\/h2>\n
3. Low risk always comes at a price<\/h2>\n
4. The first release is just the beginning<\/h2>\n
![\"App](\"https:\/\/zaven.co\/blog\/wp-content\/uploads\/2016\/04\/keep-calm-because-it-s-just-the-beginning.png\")
5. Being too optimistic about 3rd<\/sup> party tools<\/h2>\n
6. Design isn\u2019t understood clearly<\/h2>\n
7. The dev team is always one step ahead<\/h2>\n
![\"The](\"https:\/\/zaven.co\/blog\/wp-content\/uploads\/2016\/04\/Pieter_Brueghel_the_Younger-The_Parable_of_the_Blind.jpg\")
\nSummary: How to avoid hidden app development costs<\/h2>\n
\n