How much does it cost to build a mobile app? (Hint: You’re going to be disappointed!)

Be it a mobile entrepreneur or an enterprise mobility customer, they quite often face the question of how much to pay to build an app. We get this a lot and asked the folks at Thinslices  to weigh in.

“Answering on the spot is impossible, which is why we take some time, look into the client’s history, ask him what his exact needs are and only then do we offer an accurate diagnosis.”

Resources already exist online that show mobile app entrepreneurs how much they’re about to spend for the app they have in mind – ContractIQ’s own “Makers Speak 2014” survey points out the app development prices across various regions for iOS, across various skill levels.

Generalizing is tricky and we know it. Nevertheless, here is our take on the issues of expertise and costs, derived from the experience we’ve had developing several complex multi-platform mobile products.

Before we get started, you should know that the perspective of this post is of a mobile product that is complex. This generally involves a wider batch:

 

  • Native Apps. iOS, Android, and Windows 8 apps
  • Cloud. Apps can rarely survive in the wild on their own, which is why we use Node.js to create unbelievably fast (under 5ms response time) APIs that run on Amazon or Heroku.
  • Single Page Application. A companion-responsive web application that is usually developed with Angular.js.
  • Website. The mighty presentation website (WordPress-developed) that best describes the product.

How we get things done.

Over the years, working on different projects taught us that it is crucial to follow a well-established process when developing a mobile product. This helps save money and time.

StrongLoop, a key contributor to Node.js and our favorite API technology stack, once described the key stages and activities required to build a mobile app. Our approach at Thinslices is very similar. Here are the key activities we pursue when creating mobile products:

  • Concept, wireframing and design. A significant amount of time is spent at this stage to understand the problem that needs to be solved. Work is dedicated to improving the business model and defining the proper high-level solution. As an immediate next step, we start creating wireframes, while, at the same time, building design options.

The design process requires as long a timeline as possible, with some cooling-off periods that help get the best out of the creative process.

  • Prototype. During the wireframing and design process, prototypes are created on the actual mobile device. The rapid prototyping with Adobe Fireworks technique allows us to refine both navigation and screen flow and obtain an accurate view of how the mobile product will perform at a fraction of the cost.
  • Proof of Concept (PoC). The native app (or the web app) now looks and behaves just as the real thing, without the API connection – we are basically developing the front-end of the application. This allows the client to start talking to investors, and to even show the app to potential users. At this stage, it is possible to see how the app feels and behaves, while still being able to make changes at a very low cost.
  • Development. Once the PoC phase is complete, we start working on the full-blown implementation of the cloud API and we connect it to the mobile app. This process is SCRUM-organized, which gives flexibility for making changes to the product along the way.
  • Quality Assurance. We’ve already talked about this in a previous post. In  There is no such thing as bug free software, not even in the Big League, we argued that even big companies like Facebook, Paypal, Microsoft or Google struggle a lot to obtain perfect mobile products. For a small startup, however, things are even more complicated, as there sometimes are no second chances. Getting good quality is imperative, especially when an update process can take as much as two weeks before it reaches the customers (due to the Apple approval process)!

In our team we are keen on practicing Continuous Integration and acceptance testing automation (with Cucumber), in order to reduce as much risk as possible.

 

The people involved
Developing a mobile product takes time and hard work. However, none of these is as hard as getting the right people in the mix. The number of people involved in a project varies depending on its complexity and its time frame. So, if we were to sum up a selection of key roles, they would look like this:

 

  • Business analyst. Helps define the product, the major feature set, the long-term roadmap, the product backlog, the business model.
  • Product owner. This is usually the client.
  • Designers. They create the wireframes, the design, the UX and prototypes.
  • Architect. Defines the high-level technical solution and the choice for the best technology stack.
  • Developers. At least one for each technology, but not necessarily all at the same time. This means a minimum of 5-6 people: 1 x API, 1 x each native app platform, 1 x web app, and 1 x website.
  • Scrum master/ product owner assistant. Helps elicit requirements from the product owner and facilitates all processes until completion.
  • QA. Writes test plans, does the testing, the automated acceptance testing (usually with Cucumber).

This means that at least 10-11 people are needed for taking a complex mobile product from idea to market. Each of them has a different level of involvement, at a different moment in time.

The client decides how much the mobile app costs.

There’s no short definite answer for estimating costs. An app can be built on a freelance site for a few thousand dollars and even less; at the same time, ambitious plans require big budgets of hundreds of thousands. It all depends on the project scope.

But how exactly can there be such variance?

Let’s look at what all can go into an app:

It could be any or all or combinations of these : API plugin, Data Visualization, Point/Reward System, Geo-tagging, Live Chat, Media Stream, Paid Subscription, Review/Rating, Search, Social Networking, User Profiles, Navigation/Mapping, Login, Payment Processing, Sync Across Devices, Admin Site

Then there comes developer’s experience levels and location.

Having seen the breakdown of activities, the profiles of those needed to contribute to the realization of a mobile product and the variances brought by app features, developer skill levels and location, the client needs to prioritize and at times compromise on what they would like to launch.

But if we still have to hazard a guess:

If you are launching a prototype or hobby project – Spend between $5000 -25000

If you are an enterprise product that integrates with at least one system and addresses 5+ use cases & has dashboards and report – Spend between $50000 – $100000

If you are an immersive game with heavy UI, interactions and a sophisticated payments, rewards systems and animations – Spend upwards of $50000 – $250,000+

To conclude, here are some highlights on what the client should keep in mind while evaluating cost:

  • Commit to the project! You probably won’t build the next Twitter, Facebook or Evernote with just a tiny bit of cash. Starting small and “just trying out things” can prove more expensive than you’ve thought.
  • Experiment, build things in chunks, validate your knowledge, apply the Lean Startup principles!
  • Take one step at a time: find out who your audience is (iOS, Android) and start by building each platform slowly. It will be cheaper to make changes along the way.
  • Better design, speed, scalability require exponential effort. You can have great design/UX in a few days or weeks, but to make that twice as good it might take 10 times the effort and cost.
  • Keep your expectations realistic! It will be pretty hard to build something better than Google (or any other Internet giant), when they have thousands of engineers involved and you only work with 1-2 developers.
  • “Mobile first” and “mobile only” are great, but you should think really hard if you want to launch the product without a web app. For two of our customers this has turned out to be a huge barrier in user adoption and, consequently, in acquiring the next round of investment.

What activities do you consider critical when developing a multi-platform mobile product? Do you think the price levels are in line with what your experience is

See you in the comments!

PS: In case you need a free, hands-on support on picking the right app development companies for your project, tell ContractIQ about it!

About the Author:
Ilie Ghiciuc, Thinslices` CTO, has over 11 years of experience in IT&C and has delivered over 100 projects for companies in the financial, insurance, health care and publishing industries, ranging from small ones to projects that lasted 5 years and involved teams of tens of developers, using different technologies (.NET, Java, PHP, Mobile).

 

 

Building an app? Tell us about your project

We'll connect you with the right team for your project, for free!