11 steps: How to Create a Successful Mobile App? | Chapter 3

The 3rd chapter of our mini-series is here (you can read the 1st and 2nd ones here and here accordingly). Today, we’ll focus on the actual development and further launch of a developed product. As it’s a rather broad topic, I’ll try to keep it condensed and easy to read. No need to have a long intro, so…

The design stage was successfully finished, all the initial flaws of the UX were identified and fixed and green light for developers was given. The longest part of the journey is about to start.


First of all, let’s quickly run through the team members’ roles and responsibilities. Very often people who had no previous experience with IT development assume it’s only people who actually produce code are those who take part in the process of making an app, but that is far from the truth.


Developer / Programmer / Coder

The core of the team, but in many cases, especially in a bigger scale projects, require tons of support from the rest of the team. Developers focus on writing code, but it’s never perfect (that’s when QA comes into play) and they need to get a detailed description of what has to be done (and that’s the PM’s role).

Project Manager

A pretty important someone, who’s main responsibilities are:

  1. To manage the production team, plan their tasks and oversee the process of product development;
  2. Communicate with the client about the progress, eventual delays or obstacles the team have faced in the action.
QA Tester

A wizard of breaking things and finding things that don’t work. While the developers have finished coding some part of the application and move forward to build the next one, testers take that finished part and try to make it malfunction. They don’t do it because they’re evil (at least I hope so) but to make sure that the end product that will reach the market works as good as it can possibly do.

As you can imagine, everyone in the team very often dedicates their full working day to work on a particular project and therefore — their time will be a part of the end cost.


Now, the development phase. You probably would like to know how much does it take to develop an app that you can go and upload to any of the app stores out there? Well, Captain Obvious has visited me to answer this questions and the answer is — it depends. Complexity, technology stack, number of developers (more developers doesn’t mean faster development - more on Brook’s Law here), budget, state of the related open source software and many more.  

The fastest MVP we’ve developed was delivered in a roughly 1 month. It was a set of 2 mobile applications: one for riders, one for drivers and an admin panel based on our AdminBro open-source solution. This allowed our client to take the apps to their employees and test it in a real life scenarios, which gave us even more detailed feedback, which allowed us to continue rapid development of the product.


Testing is also an extremely important part of the whole process. Many companies we work with decide to add a dedicated tester to the team in order to maintain a great quality of the code and as a result the whole end product.

And even though it might seem more expensive to add another full time team member, if you plan to continue the development of the app — in the long game, you’ll save a lot of money and time that otherwise would’ve been allocated to fixing broken legacy code.

Soft launch

When the app comes closer and closer to its release date, some companies decide to mitigate the risks by executing a soft launch. In a nutshell, a soft launch is when you release your application before its release date with a main goal to prepare for the main launch. It is often rolled out to a small audience with limited or no marketing budget at all and a development team carefully watching how the app will behave in a “natural habitat”.

This approach allows the business to quickly fix the most common errors before showing it to a broader public, or, in case no critical issues were found — polish it before the initial release with a much lower cost that it would be if, for example, the marketing campaign would be in its heat and suddenly everything is crashing down and users can’t even register or change pages.

If you’d like to read more about the marketing perspective of a soft launch, I’ll gladly send you over to our friends from LiveChat. They have a dedicated piece that I think will be useful, especially, if soft launch is something new to you:

Fix bugs

What will most likely occur during the soft launch, you’ll encounter quite a number issues that require asap fixing. Businesses have a few of ways to tackle this:

Changing priorities

You move focus from further development of the product to bug fixing.

  • Pros: cheaper in the moment.
  • Cons: Slows or halts the process of adding new features.
fixing bugs

Adding a fixing team

Or you can create a separate team that will focus on fixing bugs while the main one keeps pushing forward with next functionalities.

  • Pros: no effect on the ongoing development.
  • Cons: additional budget will be needed to pay for additional developers.

Hard launch

Big game time is finally here. Your product is stable and you’re ready to go Rafiki on them and show it to the world.


Hard launch, as you can imagine, is the opposite of soft launch. You go all-in in every way possible and prepare to brace every major or minor issue that will come your way in a matter of hours. This is when something called SLA comes in extremely handy


SLA (service-level agreement) is a type of services that occur between 2 entities, for example a startup and a software development agency, in which parties agree to have out-of-office-hours cooperation. In reality, a software development company agrees to dedicate a team that will be available during agreed SLA hours, usually evening-night, in order to be able to deploy a quick fix if something suddenly stops working outside of regular working hours. Companies like Uber, for instance, can’t allow themselves to be unavailable after 5 PM just because every developer went home.

  • Pros: additional control over the stability and uptime of your apps,
  • Cons: additional costs, as usually you pay for the time that a developer is ready to start working if something goes wrong… and they might be doing nothing during this whole time, a so called “stand-by”. It’s a smaller fee, sure, but it continues to generate cost.

To go for the above solution or not — up to you, but if you have sufficient budget and your apps require 24/7 stability, it’s definitely a no-brainer.

The End?

That pretty much concludes the end of our short journey. Obviously, I didn’t tackle a lot of things like marketing, business intelligence, finances and many more that constitute an integral part of making a successful application, but I hope the described steps will help you to navigate in the world of making an app from development perspective. And whether you decide to build an in-house team or you’d like to go for a company like Software Brothers — it’s up to you. Both of those approaches have their own, unique pros and cons.

In case of any inquiries — feel free to drop me a line at ross@softwarebrothers.co. We have plenty of expertise in developing successful application and will be more than happy to help!

Good luck!