Why is it so hard to get a price estimate for a mobile app?
“I would like to have a notepad application. How much would it cost?” As a customer, this is a very important question, but as a developer, it’s pretty hard to answer. If you want to know a close estimation of the overall costs, you must provide the dev team with a proper specification.
You should think through the points below, not only to get a better estimation, but also to have a better grip of exactly what you want your project to be.
Below I gathered the important elements needed for a reliable price estimate. You need to answer all of these questions, in order for your estimate to be well grounded and dependable. If some of these points are missing from your spec info, developers will be likely to top their estimation with extra dollars/euros/whatever for the yet unspecified, though existing costs. It seems easy, however, missing parts will make the estimation a bit shaky for both you and the developers.
Checklist for a price estimate
Design Details & Visuals
In order to know the number and complexity of the screens of your app, a draft of every single one is needed. This process will make superfluous and missing functions apparent and will clear things up in your mind as well. The draft can be prepared using any kind of drawing app or even paper. Of course, there is a plethora of online tools designed for this process exactly.
Here are a few:
http://balsamiq.com/ http://codly.io/ http://framerjs.com/
A wireframe is basically the description of the relationships between your screens. The word ‘description’ is a bit misleading, because this is really a clickable draft of the screens, showing navigation options between them. Apps are not linear slideshows, users can usually go around, back and forth. It’s important to see the options for navigation. The wireframe helps us notice any missing or extra buttons on the different screens, for example, if there is information on one screen, there is usually no need to show the same thing on the next one.
Here are our favorite tools for wireframing:
This is the looks and the feels of your app. Imagine mock-ups as really high quality, colored screen drafts, perhaps applied onto your wireframe. These are useful if your app aims to be very user oriented.
There are devices available with seriously awesome performance capabilities nowadays. One of the possible ways of using these performance abilities is to spice up your surfaces with good looking, interactive animations. An animation put well, can have great effect on catching the users’ attention. However, even one little animation can require significant effort (hence, hours of work) from the developers, so it’s beneficial to think through the possibilities in advance and make an informed choice.
Here is an example:
Finally, it’s important to decide who exactly is going to carry out the final plans for the design elements. Is it part of the development deal or is it going to be carried out by an external design team? If there is an external design studio, it must be clarified where the borders lie between software development and design. For example, a piece completed in Photoshop or Sketch could be sliced (made fit for every screen) by the designers or by the developers.
Existing or new application
It is important to know whether you want
- touch-ups and error corrections,
- further development on an existing app, or
- an entirely new application developed from scratch.
If it’s case 1. or 2., the articles mentioned in the first section are only crucial if you are implementing new screens or new designs. If it’s case number 3., everything I’ve mentioned above is absolutely necessary.
To give you proper estimates, the developers have to know which platforms you prefer. Android and iOS are the most popular platforms, though, for some apps the Windows Phone form is also needed.
These would be called native apps, developed in the language meant for that specific platform. There is no unified code for these three, but solutions to specific functions should be developed using similar tools. This way your app will function and look similar to itself no matter where it’s used.
It should be mentioned here that there are also cross-platform possibilities. Many people think these are better, as applications working on all platforms can be developed from a single source code. The story is not so simple: as applications get more complex, drawbacks of cross-platform solutions become more apparent. However, we will be discussing these in another post, so keep an eye out!
All in all, platforms should be discussed and whether you want a cross-platform or native app should be decided on an informed basis.
You should definitely think through the ‘who, how, and what’ of your app. In other words, there may be various kinds of users (actors) engaging with your app. Who will they be, what will they use your app for and how will they use its features? It’s important to see the app from their perspectives and possibly correct mistakes before development starts. Thorough planning can save you a lot of money.
One of the most important parts of your specification is the description of all features. These are essentials for your app to be successful and of course with new ideas, you must make sure details are understood. Plus, I hope it goes without saying, that these descriptions should be readily available for the developers. Every single feature should have a detailed description of exactly what you expect happening:
- which pieces of data you want used,
- where we should collect data gathered,
- what should be sent back to the server.
In many cases, users’ details, various pieces of content and specific (for example, user-related, behavioral information) should be stored on a server. (For the purposes of this article: this is pretty much the backend.)
In order to have flawless communication between teams, it is optimal to have the backend and the mobile client developed together. With that said, having some kind of a minimal-functionality-administrators’-interface is necessary for every backend. Therefore, it can be seen as its own piece of software… it really is its own piece, so specification needs to be done for the backend, too.
It is also very important to specify all systems needed to connect to your app. Lots of people realize that users don’t like registering again and again as they start with new applications. Instead of having them fill out a registration form, saving users’ time with integrated Facebook or Google+ login options seems pretty evident.
Another very handy usage of integration is sharing on social networking sites. For example, without an integrated Facebook login, sharing is possible through a series of taps, whereas when a Facebook login is integrated, it only takes one tap to share.
Almost all independent systems have a development kit (or at least some kind of simpler communication option), easing their integration into your app. But the process of integrating these into your app can still be very time-consuming. Not to mention that sometimes these change so drastically with an upgrade that their updating within your app becomes necessary as well. So if you choose integration, you should calculate with at least minor ongoing support costs.
One more thing! You should think about how waiting for actions influences your app. For example, if there is a wait for a service’s called feature, could the user move onto a next step, or should we have a cool loading screen for the time being?
Deadlines are important for every area of development (and life), and of course if you need the app by yesterday, then the deadline will seriously influence the pricing as well. The timeframe isn’t only crucial for the pricing process, it’s also necessary in order to tell whether implementation is feasible.
It becomes evident that you should think through these points not only in order to get a very accurate and detailed pricing proposal, but also to think through and clear your app up in your mind as well. Clarifying these questions are interrelated; figure out some points and those will help understanding others.
Did we leave something out? If you have any questions or comments, please share! You can comment below, email us, or reach out via social media!