All too often, people dive head first into their mobile app creation with no strategy and no clue about the process. They come with preconceived notions that ignore and dismiss some really important factors in the success of the app.

You often hear people throw around the phrase “Ideas are worthless, it’s all about the implementation”. There is a case for that argument. Take a crap idea like “Yo” for instance. You can still make that project popular and financially successful although it would be quite the uphill battle. It would clearly be better to start with a good idea. If you’re trying to make money out of your app (and by the way you should be because you’re spending time and money on this), then you need to start with an app idea that has the potential to be profitable in the long run.

Let’s say you get on the app store and choose the Beauty category. As you might imagine, countless options will be presented to you. It’s easy to overlook the fact that the same exact thing will apply to your app no matter what category you end up choosing.

Say you’re an ice-cream vendor, you wouldn’t set up your shop in front of Baskin-Robbins. You can’t just think “people come here for ice cream. I sell ice cream…therefore this must be a good idea”. It just doesn’t work that way.

Ah the topic of money..Now that you’ve decided what demographic you will target, we have to figure out how to get you paid. Please don’t be one of those people who simply dismiss this part and justify that with some ridiculously disingenuous reasoning “I’m not doing this for the money”. Newsflash: you are. You are just deceiving yourself and using that as a preemptive excuse. That way, when your app makes $0, you don’t have to face your failing self and say “I made $0. This was clearly a failure”. You can just backwards rationalize it by saying “Well…I wasn’t in it for the money anyway”. Of course, this doesn’t have to happen if you set a target financial goal and have a plan to hit that target.

The final step of the Discovery stage is defining the roadmap for the project, but not the whole thing, just the Minimum Viable Product. That could mean many things though, but the easiest way to explain MVP is a testable product that is feature incomplete. Why testable? Because it helps you collect data and user feedback at an early stage. Based on this feedback, you will be making incremental improvements to the subsequent iterations.

Simply put, Information Architecture (or IA) is figuring out how all the content should be structured to maximize accessibility and ease of use. It is the user journey, the path that users will take to perform their intended action. It is in this stage that you decide which features will help users go through the journey, as well as overall functionality of your app. You also decide how to present and organize this information.

A wireframe, also called a page schematic or screen blueprint (just kidding, no one actually calls them that), is a visual guide that shows the skeletal framework of an app. It gives you an idea on the infamous “look and feel”. With a wireframe in front of you, it’s easy to explain the concept to your dev team and set reasonable expectations from the start.

Now that you have some screens to play with, you’re going to want to familiarize yourself with InVision, an essential tool of the product designer’s toolbox. This isn’t an InVision guide, but InVision is so easy to use that it doesn’t need one. Just upload your screens to InVision and link them together.

Now, I know we’ve been putting it off for a while now so this might sound contradictory but hear me out. Statistics (yes) show that 94% of the first impressions of a mobile app are based on its design. So while looks aren’t everything, it is clear that UI plays a huge part in the overall perceived quality of your app.

Although both UI and UX overlap in many aspects, they have different functions. While UX is about enhancing customers’ satisfaction level by offering optimal app usability and a smooth experience, UI defines how your app looks and behaves visually (animations and such).

Ever seen apps that use 10 different button colors, 5 different gradients, 20 fonts? Me neither. That’s because the apps we use the most everyday have designers that are aware that they can avoid this common pitfall by simply having a style guide.

This step is pretty straightforward. You’re essentially grabbing all the elements from your style guide and throwing them on top of your wireframes (ok maybe don’t throw them on top, apply them gently).

After rendering all your screens, go back to your clickable prototype and test it out again. This is the part where you want to test a lot because any changes beyond this point get SIGNIFICANTLY more expensive.

I know we said useful features and functionality are good. That’s what everyone preaches and it’s almost overdone. But this is your time to focus on the aesthetics. You can go one step further and throw in some animations and little things that might make your app stand out from the rest.

Unpopular opinion here in a time where everyone tells you to think “outside the box”. I say if you can make a nice box, then it’s ok if you’re inside the box.

At this point, you might as well involve some potential users. It will give you more perspective on how your app works and looks, and will let you know if there are any big changes you need to make before handing off to development.

So you just put a bunch of effort laying out the foundation of your app. Great. Now you just send that over to your developer, wait 12 weeks and it’s all done, congrats!

Sharing the goals of your app will allow developers to put themselves in your users’ shoes and translate those screens into software logic. List down the goals and share them with the developers as a reference to keep in mind when coding.

Your prototype gives developers a clear picture of what they are supposed to build and things to think of while developing it.

Having basic knowledge of HTML and CSS will help you structure your app design in a way that makes them easy to code for developers (or at least not too much of a pain).

So, while designers and developers work differently on various aspects of a mobile app, the goal of their work remains the same. Therefore, a smooth and healthy communication between designers and developers is paramount to delivering a quality product.

Congrats! You have now been promoted to the role of technical project manager, you’re welcome. Now, how should you approach the building of your app when it comes to the technical stack? Are you developing a mobile application for iOS or Android users? Should you use Java or PHP to build your app? Where and how should you host your app?

There are millions of approaches, but I will make it easier for you. Just choose one of the following three approaches for developing the front-end of your mobile app:

Native apps are coded for a specific mobile platform — Windows, iOS or Android. The programming language used to write these apps is supported only by the operating systems of those platforms. A native app can leverage your device’s hardware and functionality to a large extent, which elevates the user experience. It also means you can use fancy native components and patterns.

Apps developed using this approach use shared SDKs (Software Development Kit), but they still run natively. Xamarin, React Native and Native Script are common technologies used to code cross-platform native apps. While you do lose some of the native advantages, this is still the most cost-effective approach if you are on a limited budget, but still want an app designed, optimized and styled for more than one type of device.

A hybrid app is compatible with all devices and operating systems. Cost-effectiveness, portability and quick deployability are three major drivers of the popularity of the hybrid mobile app development approach. However, keep in mind you don’t get the advantages of native components and native interaction patterns so you will sacrifice some of the app’s user experience.

Now that your front-end is ready, you need some sort of data to display. Data lives in a server on the back end. To create a server that effectively communicates with the front-end, you need to develop the back-end mindfully. Consider the following factors before writing the code:

For building your app’s API, you can choose among the commonly used programming languages, those are C#, Java, Python, .NET, PHP, etc. If you’re lazy like me, you will be happy to hear that most languages come with frameworks with extensive docs so they’re easy to get into.

Commonly used databases are MySQL, MongoDB, and PostgreSQL. For this case, we’ll just keep it simple and go with the tried and true MySQL Database.

In this step, you decide how and where to host your API based on your budget and hosting costs as well as expected performance and reliability.

Once the strategy is formulated, and you have your design, the stage is set. It is now time to actually develop the app. Again, as you might have guessed by now, mobile app development is not a single step, it is an iterative process with a (big) series of steps.

Before you start developing the app, you need to set everything in place, and this is what we do in the planning phase. The planning process begins with breaking down the tasks into smaller, manageable chunks. Then the requirements are determined for each small module that is assigned to developers.

During the development phase, developers start implementing the functionality of the app. The app is then assigned back to the project manager or QA tester for review once implementation is done.

Once the first sprint is complete, the app gets to be rigorously tested in a variety of real-world scenarios, including uncommon cases referred to as edge cases. This stage helps to detect and correct any technical flaws and prevent the accumulation of technical debt. It is good practice to test the app early and often as it will minimize the final costs. The farther you move into the development phase, the harder and costlier it becomes to fix bugs.

Functional testing is conducted to ensure that the app does exactly what it is designed to do. The QA team prepares a test case to make sure the mobile app features are functioning as described in the functional specs.

Mobile performance testing is not only about how well a user gets around, but also about how efficiently the components operate under stress. This basically tells you if your app loads and responds fast. If not, then you need to go back a few steps and figure out how to cut down some fat off the app to make it perform better.

Edge case testing is typically used in edge case scenarios (yes) that occur under extreme operating conditions. It involves functional regression, unit testing, and performance testing activities.

With thousands of operating system and devices out there, it is crucial to ensure the proper functioning of the app in all platforms. Try out all appropriate screen sizes and OS versions while testing your app.

This may sound similar but they are actually two distinct processes, and both are equally important. With UT, the QA team ensures that the features meet the functional requirements. On the other hand, UAT allows you to ensure that features are meeting the requirement from the end user’s perspective.

At the end of the testing phase, it is time to review the app. If there are still some minor issues (and trust me, there will be), that’s ok. We need to keep it moving forward though so you can push those to future sprints. Once the review is done, start the planning for the subsequent sprints and continue the process until the app is ready to be deployed.

When you are done with complete app development and testing, it is time for deployment. Deploying an app calls for proper planning to ensure that the integrity of the live environment is protected and correct components are released. This stage is very dense and involves a lot of moving parts. For this post, we’ll keep it short. Here’s a quick checklist of things to be mindful of:

There should be a well-defined release cycle plan in place to ensure a smooth deployment of your mobile app. Read more about release cycles.

Minimize downtime and prevent large download files by using continuous deployment as part of the release. Read more about continuous development.

Before deploying your app to any commercial app stores, ensure developer certificates are up-to-date. Read more about dev certifications.

You can save time by automating stuff like configuration and provision according to established policies and profiles. This will actually also result in significant cuts in costs.

Defining the development, production and testing environment of the hosting environment is also crucial for deployment.

Lastly ensure all the features of your app such as signature, version, compatibility, etc. are updated before deployment to prevent the delay.

A server back-end is required by most of the mobile apps to work. This enables the data transfer in the app which means your app will not work if the server is overloaded or stops working. Choose a properly configured server that can meet the potential user base without being needlessly expensive.

Before submitting your mobile app to an app store, ensure that your apps are properly configured for release. You may have to fill out some forms, submit marketing materials and screenshots and descriptions. Additionally, Apple has a manual review process to verify all apps submitted to their app store. Hence, you may need to make changes to your mobile app to better comply with their system.

Google Play also has its own app submission and review process just like Apple. The app submission process of Google Play is quite similar to that of the Apple App Store. You just need to provide some app info such as app icons, screenshots, and description.

The mobile app development process doesn’t end with the deployment. Your app will have to further go through performance improvements, changes, and the addition of new features. Monitoring your app will give you a full picture of the user experience and the updates that your app needs.

It is crucial to gauge both launches and resume time as it impacts the user experience. FYI it takes longer for an app to startup than resuming while running in the background.

Crashes can obviously drive users away so it is important to track them down. You should know the user actions that resulted in crash, what type of device was used and other technical information that might help you resolve the issue.

It is also important to monitor the way your app responds to users. Response time represents the speed at which the app reacts to user inputs. For instance, how fast your app displays the search result or how fast it completes a transaction etc.

You can use analytics to keep track of the users who are using your apps and how they are using them. You can even learn about some really useful metrics like which buttons are tapped most often on the screen. All these valuable insights will help you best understand where you need further improvements.

You will want to have a robust performance monitoring system in place to know how quickly your app works. This will help you figure out the areas to optimize. You should check out for example if any particular actions are taking more time than expected.

Regular monitoring of App Store ratings and reviews are crucial for your newly developed mobile app. Try to engage the reviewer and assist the frustrated ones and it will go a long way in enhancing your online reputation.

A mobile app that drains the battery too quickly will be sure to frustrate the living hell out of a user. Because of that, be sure to gauge the battery consumption of your app. There are many factors that cause battery drainage. Rethink the way your app is built if it is causing more battery consumption and find out how you can get it to comply with best practices. Make the necessary changes to keep the power consumption of your app at an absolute minimum to keep user satisfaction up.

Aside from battery consumption, another factor that annoys the user is the consumption of cellular data. Don’t you hate it when a mobile app devours all of your data plan? Right. So make sure to figure out which user actions consume the most data and measure the kilobytes of data consumed per minute of use.

Now that you’ve monitor all of these metrics with the help of this blog post and your fancy analytics tools, let’s put that data to good use. Upgrading your app with your new insights will not only enhance its visibility but also increase app downloads. You have to keep updating the app to meet the evolving user expectations as well as meet ever-changing guidelines of various platforms.

Look I know you have poured out all your efforts and time to develop this app, but there will always be room for improvement. User insights and competitors research can help you ideate on new features and keep your app fresh and up to date.

Scaling impacts the way the app reacts to the kind of traffic it receives. Scaling your mobile app will require you to allocate the appropriate required resources to the app as it grows. This resource allocation enables you to make the app better at handling the huge traffic generated by your successful app. You never really know if/when your app will go viral, so keep on improving the app while keeping in mind data distribution at massive scale.

Another factor that needs to be monitored and improved is its security. Ensure that network traffic between the app and the server is encrypted and involve user authentication and authorization while accessing sensitive information.

If you are reading this, chances are you just went through this massive post to learn how to develop your mobile app. Congrats! Hopefully you have learned a thing or two about what goes into building a mobile app from scratch. If you think I missed a critical stage of you want to find out more about a particular step of the process, feel free to leave a comment with questions/suggestions and tell me about the apps you’re building, I promise I won’t steal your ideas ;)