android app cost

All android apps look alike in terms of running on multiple platforms, there’s a big difference within the scale of apps, their use cases, etc. The size of an app broadly defines the event time and therefore the cost involved, whereas the precise features involved further define the timeline.

Following may be a brief description of what are the factors involved in App development and the way they affect project duration and price

The scale of the Android App

One common app misconception in beginners is — a selected feature, say, push notification, will always take a similar time in development and hence, should be provided at a fixed time and price.

The difference arises from the size of the app. There are broadly three scales for mobile apps:

1. Personal / Hobby Apps

These are android apps made for private/ group use and mostly involve a private idea which you would like to share. Examples are — My Travel Diary, My Joke Book, Personal Birthday Calendar, etc. These are the foremost recent ones.

These apps are limited to a very small number of individuals. The advantage is, these apps are often made in a super agile manner i.e. apps are often developed as quickly as possible and provided to the finished user. End-users then provide feedback, which drives modification and repeat. This way, the wants of end-users are fulfilled by their own testing.

Even if these apps involve a server and back-end code, everything is (and is meant to be) minimally maintained, because if any problem arises, which will remain limited therein a group of individuals. The matter is often quickly identified and resolved.

Personal Apps

All these features of private apps reduce the event time and price drastically because:

  • Back-end schema/architecture needn’t be 100% defined before starting and even after release, as changes are often easily made.
  • No full-scale testing is required because end-users are very small in number and themselves act as testers.
  • No separate development and production server and databases required.
  • No regular backups etc required.
  • Testing and development remain limited to the sort of devices that the group has. E.g. If all of them have iPhone, no got to develop the app in android.
  • Testing includes most general cases of usage e.g. internet is usually available, the app is allowed all permissions required to figure properly, etc.
  • A big difference arises due to the group associated with the app. Albeit the app shows any error, these users won’t throw the app away. The app is specifically made for them and hence they’re going to provide feedback, and await the resolution. This provides an enormous relief on the android app maintenance side.

2. Intermediate level apps

These are android apps that have a bigger scale than personal apps, with few hundreds to few thousand users. These are mostly made for little businesses, startups, or maybe for brand spanking new growing ideas.

The most important difference from the personal app is that the user group isn’t defined. e.g. A quiz app made for college kids. Although you recognize the demographics and their requirement, you don’t exactly know what devices they need, what quiet internet connection they need, etc.

These apps are mostly free on app stores (or very small price) but intended to realize a lot of users. Plus these apps do have competitors.

In this case, most app requirements are defined before starting. The pre-release development of the app mostly goes in an agile manner, the same way as personal apps. The difference comes in during-release and post-release scenarios. The app requires thorough testing and post-release maintenance hooked into user feedback.

Intermediate level apps

The differences from personal apps are:

  • Back-end schema/architecture is usually defined when starting but is often changed during development.
  • Full-scale testing is required because end-users are very decent in number. Although, alpha and beta testing can still be avoided.
  • No separate development and production server and databases required.
  • Backups are taken once in a while.
  • Multiple device scenarios are considered during testing, a minimum of covering >75% of the market.
  • Testing includes more scenarios compared to non-public apps e.g. internet isn’t available, the app is denied permissions, etc.
  • A good feedback system is required to capture any errors the users face. This leads to a faster resolution of bugs.
    For these reasons, intermediate apps take 2–3 times the event time and price, compared to a private app.

3. Enterprise level apps

Note: These aren’t ‘Enterprise’ apps, these are ‘Enterprise Level’ apps. In other words, an enormous Enterprise also can have a private app or an intermediate app.

Enterprise-level android apps are those where your whole business model stands on the app e.g. Twitter, Tinder, etc. The user number goes from a few thousand to even a million. There’s an enormous competition once you are aiming that big, plus user retention may be a huge issue.

Enterprise-level apps generally have:

  • Back-end schema/architecture 100% defined when starting. Any change during app development or post-release goes through a full series of testing.
  • Rigorous full-scale testing is required because end-users are very large in number. Plus, alpha, beta, and A/B testing are done.
  • Separate development and production server and databases required. Once a version is released, all further development or bug fixes continue to the event server, fully tested then released on the production server.
  • Regular data backups are taken. A backup production server is additionally considered in some cases, where app outage means serious business loss.
  • Multiple device scenarios are considered during testing, a minimum of covering >80–90% of the market. A fanatical group of testers is required for this
  • Testing includes most scenarios compared to personal/intermediate apps e.g. what if a call comes in when using some feature of the app, what if the internet goes away within the middle of an action, what if the phone turns off within the middle of some action etc.
  • A good feedback system is required to capture any errors the users face. This leads to a faster resolution of bugs.
  • These apps sometimes push the bounds of features provided by the devices, servers, etc. Hence keeping in the loop of all concerned technologies’ support teams results in quicker resolution of mega problems like a server crashing.

For these reasons, enterprise-level apps take 2–3 times the event time and price, compared to an intermediate app.

2 comments

Leave a Reply