What you need to know before start developing a mobile app in 2020 - a guide for non-tech people
I assume that you are at the moment when you have examined the problem you want to solve using the mobile application. You have - or better yet in the form of mock-ups, the solution you want to create.
You don't have technical competence, but you know that this is the right time to start developing your application. What should you take the next step?
The next step is to find a contractor (software development house) who will do the MVP for you. What to follow? What to look for when choosing? Here are tips that you should take into account if you do not want your adventure to end quickly with a disaster.
Vision and mission
The development team should be interested in understanding the vision and mission of the product you want to build. You want to find a company that will want to get involved in creating your product in the long term. A supplier who will want to support you with his experience and competence. If the companies you are going to talk to focus only on assessing your development work as soon as possible, without a good understanding of "WHY," be better alert. This will mean that the contractor is not thinking about working with you in the long term.
You want to use MVP to verify the hypotheses related to the problem you are assuming that your users have. Define the goals you want to achieve thanks to this MVP. Describe how you will do it? The team you choose to implement MVP must necessarily understand what you want to make because only then will you start to swim in one direction - to the goal!
By defining goals and measures, your team will be able to help you reach it as quickly as possible. It will provide you with advice and help, and will not focus only on providing all the functionalities that you have defined so far.
Features - analysis
What functionalities are necessary, but is it essential to achieve the goals you set for MVP?
Remember that it's better to do them less, but in such a way that you will solve the user problem better than more, hoping that everyone will find something for themselves - they will not see. The product at the MVP stage that you are trying to solve many problems has a very high risk of failure.
If the provider suggests adding functionality instead of proposing to limit their quantity, then something is probably wrong.
This is a very complex topic. On the one hand, you would like the technology to be modular, and you would not have to rewrite it all in the event of changes in requirements.
On the other hand, you are at the MVP stage, where investing in highly scalable technologies that have no limitations doesn't make much sense. Look for compromises and techniques that will help you achieve your business goals. You need to know that no matter what technology you choose, due to changing requirements, system versions, sooner or later, you will need so-called refactoring.
You want to create a mobile application.
You can choose the following technologies:
Creating the application natively for ios and android
Use cross-platform technology, such as: - Xamarin - React.Native - Flutter
Use hybrid technologies such as: - ICONIC - PhoneGap -PWA
How to choose technology? Or maybe it's better to click MVP in a tool where you can simulate the operation of a mobile application?
It all depends on the goals you set for your MVP. The second factor you should consider is the skills and experience of the team that will implement your project.
A good team will get more from react. Native than a weak team from xamarin technology.
Blockers: There is a risk that at some point in the life of your product, it will turn out that the selected technologies do not fully match the current needs. There may be requirements that, for example, cannot be implemented in React.
Native technology. Recently it happened to Airbnb. Is this a problem? Certainly yes, but if the persons responsible for MVP of the Airbnb application returned to the time when they were working on it, it would turn out that it was the best choice then. Approach this topic in the same way as Airbnb :)
The architecture of the application being built
Architecture answers the question of what components the application you are building will consist of. This is a very technical issue, but it's worth thinking about it. From my experience, it's better to choose a technology that has more limitations but has well-designed architecture than the other way around.
The most important thing when estimating an application is its purpose. Never get trapped in the fact that thanks to the estimation, you will receive information on how many hours it takes to implement all functionalities that have been agreed with the team.
Make sure that the goal of the estimation is to set a budget within which the team will provide as much business value as possible.
A committed team
As someone said - an idea is worth 1 euro - the most important thing is performance. From the very beginning, build the commitment of the team that will develop your application. Do your best to make the team be on your side from the very beginning, and understand what you want to achieve. You can count on his support and commitment. Remember that on the other hand, you have professionals and professionals. At the same time, they are the same people as you. Building engagement requires a moment. What should you pay attention to?
Don't treat the team as people from implementing screens and buttons - let them suggest ideas that will make your application better
Work on open communication - also in situations where not everything goes according to plan
Let the team propose solutions - the more the team feels the product owner, the more it will propose
Talk about business goals and how you want to achieve them. A broader perspective will allow the team to integrate more with the "mission" that the product is to fulfill
Listen to the needs of the group - such slogans as "code refactoring," "automatic tests" should not be a mystery to you, but a signal that the team wants to provide the highest value
Make sure that your team uses mechanisms to automate the process of building the application and giving subsequent versions from the beginning of development. Do not let these activities take place manually - you will lose too much valuable time. If your team does not have the appropriate competence, please take a moment to learn - it will pay for itself many times.
It measures what needs to be measured
From the very beginning measure, what is essential in the application. Do users login to the application they are using? This is invaluable information that will let you know where you are and what direction you should follow.
MVP is just the beginning
The release of version 1.0 means that you are only at the beginning of the road, and you should do everything to ensure that the same development team continues to develop your application. Think long-term and do everything to make your development team - or at least its core involved in creating your product long-term. Thanks to this, you will save a lot of time and money, and the built commitment will be paid back many times.
Creating software products is a complicated opinion. I hope that thanks to this article I have explained this subject to you a little bit!