To the uninitiated there is often a misconception when it comes to the resources required to develop a mobile app. The general idea is that you partner with a mobile app development company, tell them your idea, fork over a wad of money, and then in a preset amount of time the developer returns with an app ready for launch. This line of thinking is attractive in its simplicity, however it just doesn’t represent the reality of the situation.
The RFP
It is often said that the devil is in the details, and this is none more true than in the initial stage of the mobile app development process. While no code is ever written at this stage, one can argue that it is perhaps the most important stage of all. At this point the developer will receive an RFP or Request for Proposal. This is a document that basically lays out the clients wants and needs from the mobile app. The developer may choose to work with the client on the production of this document as every developer has varying pieces of information that they deem necessary to produce a quality app.
It cannot be overstated how important it is to get granular details into the RFP. Technical information is of course at the top of the list. The developer should know what kind of screens, features and functionalities the client wants developed. The same goes with time horizons, deadlines and launch dates. However, a good development company will also take target audience demographics, avenues of monetization and competition differentiation into consideration.
Sibers, a mobile app development company in Russia:
For us at Sibers it is vital to understand client’s business at the very first stage of the project: target audience of the future application, way of monetization, how this particular application will be different from similar ones. Knowing that we can use our experience much more wisely while helping our clients to polish their idea and to turn it into the desired mobile app. So the most important thing we need is client’s readiness to answer our questions (we assure we take all actions on protection of client’s IP).
Unfortunately, quite often clients provide a kind of specification (which is rarely full enough or structured properly) and assume that it should completely omit any questions from our side. However, when talking about an ideal specification for a mobile project we consider it consisting of three parts:
- High-level description of a project. One page of text maximum telling us exactly what and whom this application is for and what will make it stand out. Quite often clients skip this step going straight to overly detailed description on 50 pages with overview of every screen and button so it’s difficult to see the whole picture
- Scheme of the application, showing relationships and connections between screens. It is extremely helpful for estimation and further development, because it allows to define the structure and easily break down the application to logical parts or, for instance, prioritize the features to make the first version faster and cheaper, and then to continue app improvement broadening its functionality, adding new features according to their priority
- Detailed description of every screen and feature
Such specification will allow us to efficiently figure out raison d’être of the application and estimate it, avoiding leaving out any features or overestimating a feature’s complexity. Though we understand that to create such document client needs to have an experience in technical writing and also spend significant time on that. If that’s not the case, our IT consultants will help with that.
We couldn’t be more happy with those clients whose flexible approach and experience in outsourcing allow them to make a decision on programming provider relying on a wide price fork provided. So they don’t even want to get an accurate estimation at the start of the project.
The technical knowledge of a client
Some clients may be worried that they do not possess the technical ins and outs of mobile app development, however the majority of developers already know this to be the case. Developers know that clients are approaching them to create the app because they cannot do it themselves. Mobile app development companies know that they are the specialists that clients are relying on to bring their app ideas to life and, for the most part, do not expect the client to have in-depth knowledge about the technical aspects of app development.
The only difference is the way we will build our conversation with the client. If the client has close to none technical knowledge, then he or she will come to us with a demand and we will offer possible solutions based on that demand, but all the technical details will be left to us as professionals to deal with.
If the client is an expert in technical field, maybe even a developer himself, then we will be able to have a substantive discussion and, for example, to choose a technology based on client’s preferences. So both of these opposite poles are practically the same in terms of “accuracy” of a quote.
The only issue that is going to increase the quote occurs when client tries to go against the universal rule of “if you aren’t sure you are an expert in something, leave said something to a professional”. Unfortunately, sometimes we come across cases, when client hears about some kind of technological solution being good and he comes to us with a demand to use that exact technology, despite it being unsuitable and more time-consuming in case of the particular application.
So it’s our obvious, but nevertheless, important advice for anyone considering developing of any kind of application: don’t “play” a programmer. That’s exactly the reason why IT outsourcing exists, so that our clients don’t have to become programmers themselves. But our team is equally happy to see an experienced developer as our client and be able to speak the same language with him.
This leads to a question about the information we require for a project cost and time estimation. When you’re creating specification for a project it’s more important to understand what you shouldn’t do, than to know what you should do.
Let’s say you want to develop a mobile application. You have an idea. What would be the first thing for you to do? Rational decision would be to somehow formulate your idea so you could explain it to a professional. That’s when you start to search for help online. You find dozens of tools that offer you to create interactive wireframes that will almost look like a real application. And for a lot of people that seems to be a great idea, because they think that it will clearly explain to a developer what you want to make.
But if we imagine the process of development of a mobile application as building a car, then specification will be a scheme of that car and interactive wireframes will be a Lego model of this car. Yes, you might be able to open doors of this model or spin the wheels. But will be an engineer able to build an actual working car using that model? It will be much more difficult for him and probably even impossible to translate that model to a working thing.
The category of the mobile app
Knowledgeable and experienced developers, such as the ones we have interviewed, have a rough idea of the budget involved with apps in each category. Suffice it to say, some categories have a higher associated cost than others. Games, for example, that need multiple screens, varying inputs and outputs, and connection to social media will be more expensive than say a utility or productivity app. However, keep in mind that budgets based on category alone are an approximation at best. There are various complexities and client needs, such as extended support coverage, that can cause the budget to fluctuate.
Minimum budget is an existing thing and we can determine it for every mobile app category. But it will be different from developer’s and client’s points of view, since developers won’t include into minimal budget any features that aren’t decisive, but on practice that not-decisive functionality “makes” the application for the user.
That’s why games are always expensive (let’s say starting at $20,000), except for the simple ones with new outstanding ideas like in “Flappy bird”. Even if the development of the game takes 2 weeks, it will also take a year of designer’s work to create all those shiny animations that make a game popular among users. And even from the development side, nowadays games usually have social elements in them: record tables, sharing your resources with friends, etc. That can take a significant amount of time to make due to working with third-party components.
Retail applications are relatively cheap since most of them are a catalogue with added online ordering functionality. So the structure is pretty simple as well as design and there are even some ready solutions specifically for retail. To the same category we can put some educational applications in form of catalogues of different media resources (articles, pictures, videos) that we show using a certain algorithm.
Misleadingly simple look applications for making notes or fitness diaries. Saving information about your exercises is, indeed, a simple feature, but no one wants an application with that basic core functionality. And minimum time budget starts to grow from two weeks of development to years in the course of adding integration with HealthKit, social media and other.
iOS vs Android vs Windows mobile apps cost
It seems that mobile platform wars do not exist just on store shelves. For clients the struggle comes in determining which platform to develop on. iOS, Android or Windows mobile? Should the app be initially launched on one or on all? Developers usually have a fairly good idea on the real costs of each platform, and are more than willing on sharing their thoughts and views on how to proceed.
If we talk about native development for iOS, Android or Windows Phone, then we can say that hardly something will be definitely cheaper or more expensive. The difference generally will be around 10-15%. It is a whole another story the functionalities you can implement on one platform and can’t on another one (because of the application store rules or device and OS technical limitations).
Cross-platform solutions like Xamarin for both iOS and Android will be roughly speaking equal to develop two separate native applications.
Often clients’ demand is to cover as large audience as possible and they decide to settle with Android straight away, since Android devices have a wider price segment and hence more likely to cover more users from different social groups. But there is a nuance clients tend to forget about: with the wide range of devices comes wide range of technical characteristics of said devices. So to cover more than just a few flagman Android smartphones, you have to invest more into testing and bugfixing for every given device.
Marketing services included?
The majority of clients can essentially be thought of as idea generators. They come up with the concept of the app but do not necessarily possess the technical capabilities, whether it is coding or marketing prowess, to bring the app to market. It would be incorrect to assume that developers should be relied on to market or promote the app. Yes, they dabble in the marketing aspect of apps but only to collect the data necessary to optimize and complete the app. Mobile app developers are first and foremost professional programmers. They mainly provide an app building service, not an app marketing service.
We don’t provide marketing services. We are programming professionals. That is what we are doing for the last 18 years. We know how to craft an application to enhance user experience and as said above we are believers in a rule that “if you aren’t sure you an expert in something, leave said something to a professional”.
Moreover we’re strong believers that marketing should be local, because promotion strongly depends on dozens of conditions: state of the market, date of release, mentality of the target audience, etc. Though we’re ready to advise several agencies we had positive experience of collaboration with to our clients in case they need one.
Updates or maintenance of mobile apps
Apps are not a “one and done” project. Rarely is an app created and both client and developer walk away from each other and never have contact again. What if there’s an unforeseen glitch? What if new code is needed? What if standard and practices in the platform change? A developer worth their weight in salt will always provide some sort of maintenance or on-going coverage to their clients. The length of time this coverage exists and the extent of work expected of the developers is usually stipulated before a single line of code is ever written. Also, developers may also offer extended coverage that the client can purchase which ensures that they have access to the developers for months or years to come.
We’re always glad to continue maintenance of the mobile app after the release, preparing updates and new versions as needed, like recently quite a few applications needed to move from parse.com to other backend services due to its shutdown.
Unfortunately, not every client understands the importance of timely updates. For example, the release of iOS 10 is planned on October 2016, but beta version is already available and we can start testing compatibility of existing applications in advance to avoid any problems upon official release of operating system.
But surely there are always a lot of applications that don’t get updated until they stop working after iOS update, despite Apple efforts to avoid that. Of course, updating the application in advance can be a bit more expensive then postfactum due to beta version of the operating system being buggy and lacking some functionality, but in most cases overpaying 10% in advance is much more profitable than leaving application not properly working for a month after the OS release.
As for the price scheme, we work at a fixed price as well as by hours depending on the type of the tasks. If update is related to new operating system as we previously described, we advise to work by hours, since otherwise all the risks (that are unavoidable in this case) will be incorporated in the fix price.
Elements of a mobile app
There are a lot of components to a well-made app, and while it may be easy say that all developers work in the same way, this is simply not the case. Different developers may take slightly different approaches to the development of the app. Some may spend an inordinate amount of time on the wireframes, while other mobile app development companies may focus a lot of attention in source code development. This difference can depend on a host of factors which includes the developers personal familiarity with that particular phase of development, or it can be that particular step for this particular project does require a significant amount of work.
There are parts of development that you can estimate more or less precise. For example, if we take a mail sending functionality, we have a certain criteria on when that functionality is done, when the application sends emails, hence we can estimate how long it will take us to make it.
But how can we possibly measure satisfaction of a user of the application? That last phase of development, polishing phase can be perfectly described by the phrase “We’ve done 90%, there is another 90% left”. At first you develop all the functionalities and then you can spend practically unlimited time creating a trade dress for each functionality. And second, 90% of the tasks are often underestimated by the customers.
The app security is implicit, we take it very seriously by default and it never gets a separate paragraph in the estimation. Even if clients ask us to specifically develop an insecure mobile app, we would hardly agree to such conditions.
Working with third-party components is another part that is hard to estimate and integration with those usually requires significant amount of time.
Application publishing rarely causes any difficulties and doesn’t require a long time, except, of course, publishing around Christmas time. But we came across one case, when App Store did not allow applications release due to Apple’s plans to add similar functionality into the next version of the operating system. The application was published nevertheless and had a huge success, but in that case, the publishing time was significantly longer.
Conclusion
Undoubtedly, a lot goes into the determination of the resources required to bring an app from paper to the marketplace. To get the most accurate values of the money and time needed, the client must strive to give the developer as much information, details and nuances as possible. Handing developers a one or two page briefer, a bag of money and a deadline is simply not an option.
App development requires constant back and forth communication between developer and client. It requires constant research and pivots. In the end the real value of apps cannot be summed up purely in dollars and hours of work, but in the interactions and relationship between client and developer.