Mobile Development Primer

The popularity of mobile, particularly smartphones, has resulted in many individuals and companies approaching me with ideas for mobile development. Some people aren’t from the mobile ecosystem or even from a software development background.These people ask how they can go about developing a mobile idea.

These tips will hopefully help you see mobile from a developer’s point of view and hence gain a head start. This primer is suitable for a range of people…

  • Entrepreneurs and business owners considering mobile development
  • Students learning about mobile
  • Analysts wanting to understand mobile development
  • Investors wishing to learn about the mobile development process

This primer links into my site (highlighted) where I explain or cover particular aspects in more detail. Please contact me if you wish to take things further and discuss issues and development specific to your particular project. I take on work through my own Ltd company in the UK and can also recommend other developers when work is outside my remit.

1. Check Your Idea is Feasible

It’s too easy to buy into an idea and commit significant resources only to find very late on that it’s overly difficult or impossible to implement. Do research upfront. Test risky areas. Consider creating a low cost proof of concept exercising risky areas. Fail early, not later. Related to technical feasibility is the choice of mobile platform…

2. Choose Your Mobile Platform(s)

These days you will be choosing one or more of Android, iOS or web based or hybrid. The main factors are the type of app, geography (some platforms are more popular in some countries than others), demographics (e.g. some platforms are used more by enterprise or by particular age groups) or the market (some platforms have better routes to market or better monetisation). Visit my market research site to discover the latest information from research houses such as IDC, Canalys and Gartner.

Irrespective of market research insights, you should take a survey of your intended users’ device types and in some cases their future purchase intentions. Don’t just assume your intended users use the phone type you use. Also take a look at Android first and consider that there are some projects that only work on Android. There’s also a move to mobile only.

3. Start Creating a Business Model and Determine a Business Process

Just because your idea’s an app or mobile web site doesn’t mean you don’t need a business model. Take a look at Business Model Generation and start filling your key activities, partners, resources, cost structure, customer relationships, segments, value propositions, channels and revenue streams as you work through this primer.

Research Lean and Agile and determine your business process strategy based on your business needs. You might also like to take a look at the Lean Canvas which is a lean version of the business model generation mentioned above.

Never determine your process, or many other things for that matter, just because someone says ‘this is the best/standard’ way. Question whether such decisions should be based on your business needs.

4. Think About OS Version Variants and Form Factors

Think about what OS versions and/or devices you will support. Most iOS users tend to be on the latest version when their device has been able to be upgraded. Android has a large number of OS versions and literally thousands of devices. This tends to become more of a problem when the app uses deeper APIs. If you take some precautions then Android fragmentation should not be problem.

Think about if and how you want to support tablets and tablet specific functionality and screen formats. Also think how your idea might look in both horizontal and vertical aspect ratios. While it’s frowned upon, it’s possible to limit to horizontal or vertical orientation so as to simplify design and development to reduce costs.

5. Work out How Much It Will Cost

Most projects take between a few weeks and a few months per platform. Looking at my past projects, the average time to create a non-trivial mobile application is about 6 to 8 weeks. In fact, if your project is larger than that then you are probably trying to do too much for your first iteration. You might be better doing less and improving the application later based on user feedback and ideas – that will nearly always be different and better than if you had try to create the ideas yourself.

Professional European and N American developers charge between £300 (about $450, €330) and £650 (about $980, €720) per day. The variation in price depends on experience, whether freelance or small mobile company. Hence, the cost of an average project will be of the order of tens of thousands of pounds, dollars or Euros. Double to treble the cost if you are developing via a media agency or other intermediary. Reduce the cost by a factor or four to five if you are willing to offshore to typically Russia or India.

If the above costings are well outside your funding levels then take a look at my tips on developing apps on a budget.

Consider accelerators but be aware, outside the US, that relatively few (e.g. 0.01% in the UK) of companies go this route and financial amounts are usually too small to take the company through the accelerator scheme.

Consider that most apps also need ongoing development beyond that initially envisaged.

6. Consider Funding and Monetisation

Who will pay for the development? Does your idea need to make money and if so how? You will need to consider more sophisticated schemes such as in app purchases (IAP) if you are expecting to make money from users. Generally, on both Android and iOS, only games make money by selling the app itself and even these are increasingly IAP funded. The people making the real money are those that are supplying apps for free and instead selling or promoting something else.

Think about partnering to gain funding. However choose symbiotic partners over revenue share partners. Avoid ending up having too many partners.

Download the free Apponomics book.

7. Decide How You Will Market Your App and Retain Users

There are so many apps now that you have to do a lot more than just list your app on an app store. Allied to this, and just as important, is retaining all the users you do attract.

Think about designing in marketing. Avoid common marketing flaws. Include marketing objectives as part of the requirements. Quickly detect and solve top app frustrations so that people don’t end up giving you a bad review and not returning. Take a serious look at analytics. Make the most of your top users. Leverage Facebook. Also take a look at the insights from a Mobile Monday event on Mobile Marketing.

Learn how you will need to design for retention and how this is linked to contextual content.

8. Choose a Designer?

Someone needs to architect the project, decide on the functionality, refine and iterate during development. This might be you, a manager, a 3rd party or even the developer. whoever you choose, consider having developer involvement in screen planning.

Take care to design for the platform you are targeting and not end up implementing iOS UI idioms on Android or vice versa. Learn about the trend of vertical-only apps.

9. Think About the Backend (Server)

Most apps need to communicate with a server to send or receive information and notifications. Think about scalability. Look into mobile cloud computing, server side IO and Bandwidth, network latency, and backup.

There’s a growing number of hosted services that allow you to concentrate on your smartphone apps while leaving the server-side to someone else. This is called Backend as a Service (BaaS). Google also have a Mobile Backend Starter.

I have been surprised as to how many of my clients end up significantly re-engineering their server side due to new requirements. Hence, I recommend you keep things simple to start and expect to iterate. Also, with so many options for development, it’s easy to end up over-complicating things and get locked into particular server side technologies and/or cloud services. For a startup, a lot can be initially achieved using an inexpensive dedicated server, standard simple web technologies (php, .net etc.) and hence ‘standard’ web developers.

10. Choose a Developer

People tend to be too casual about choosing a developer. Ask for case studies and references. Developers should be able to put you in touch with their past clients who should be more than happy to have an informal telephone chat or email conversation.

Choose developers who can give you an overall continuously updated plan and release weekly so you can see what’s been done as work progresses. This allows you to share in decisions, problems and achievements, change the way something has been implemented (before more is done the same way), help informally test what’s been done and even provide early alpha and beta versions to your potential customers or partners.

Also think about whether you wish the mobile developer to also take on the server side. Mobile developer day rates tend to be up to double web developer rates. However, splitting the work can create additional communication and timing (planning) complications.

Try to communicate with the person or people who will end up doing the work. It’s important you know the actual person will be doing the actual development. Good communication is very important. Their skill, previous experience, attitude and passion for mobile will greatly influence the success of your project. Look for evidence of communication and foresight. Choose the wrong developer and you might end up with a working app but end up in technical debt.

11. Think Deeper

The saying goes ‘The devil is in the detail’. Here are some common issues to get you thinking…

  • One app or many?
  • Changing behaviour when the user is roaming (e.g. high data costs).
  • Diagnosing end-user problems via error logs. Keeping particular data secure.
  • Maintaining or deleting data when a new version is installed.
  • Defining what happens when the phone runs out of memory or storage.
  • Defining what happens if the application gets interrupted (e.g. incoming SMS or phone call).
  • Defining what happens when only part of a multiple-step operation succeeds (e.g. data atomicity).
  • The complexities of time.
  • Supporting foreign language variants of the phone (particularly different directory names).
  • The user reinstalling from storage to memory card.
  • The user changing their registration details (email, name, address etc).
  • The user opting out of a service (e.g. deleting data).
  • How secure does the data need to be? Create some security requirements.