We have collected the top 7 mistakes that are often made when developing a mobile application or website for a marketplace. We deliberately do not sort them by rating, because depending on the type of project and the preparedness of the client, the impact of the described moments changes. Try to avoid these mistakes in your project.
The first version is a huge “elephant”
It happens that when developing a site or application from scratch, the task is to develop not 20 screens, but 40, 50 or more. Because of this, the launch work is stretched for a year instead of 3-4 months. And if something went wrong, it will be very painful to return everything back or even impossible. So it’s best to stick to short, simple releases that both you and the programmers can understand.
Business hypothesis not tested
This point follows from the previous one. That is, the marketplace is developed only because there is a cool idea. It’s just that the same project has been launched in the West or a new technology has come out. Often they don’t think about any success metrics at all. For example, what happens if 300 users use the application in the first month and they send 20 applications? Is this enough for business or not enough? Perhaps budgeting for launch and marketing costs?
Hope for the technology, not the business process
When a clone of Yudu is made, but rewritten in a new fashionable language (Darth, for example) and it is assumed that only due to this the business model will work. Won’t work. If your marketplace has nothing new or valuable from the client’s point of view, but only new technologies, it’s better to forget about this idea, as it will be expensive and unpromising.
Technology can help you do something cheaper, something faster, provide some additional value, that is, help you make money on what others do not. But technology cannot be the basis of the business process itself or monetization. The basis of monetization should come from the benefit of your user who brings you money.
Developer Savings
In our experience, 60 percent of clients are people who have been burned one or more times on freelancers. Savings on the developer led to the fact that he simply could not cope with the task due to lack of experience, so it was necessary either to redo a lot or to develop it all over again. The desire to save money is understandable, but the miser pays twice.
Requirements for MVP (minimum viable product) as market leaders
This often happens with the development of messengers. For example, there is a requirement to keep 10 million online connections, but there is no understanding when these 10 million users will be, how they will be reached, why there are 10 million online connections at all, but the requirements are still set. Based on them, the development estimate is calculated and if you need to withstand high loads, then the cost will be at least 3 million rubles. But if the task were set in such a way that in the first year there were less than 100 thousand online users, then the development would be estimated at 10 times cheaper.
Here it is important to correlate your own ambitions and capabilities. Maybe it makes sense to first launch an MVP that will hold a thousand users, and when you hit this threshold, do some refactoring and introduce technologies for high loads. That is, there is no need to run ahead of the locomotive and put forward demands that are not achievable in the next few months. Sometimes it’s more profitable to set lower requirements and change them gradually than to immediately set too high ones and pay for it with a larger budget.
Lack of conclusions
When something is created, you need to understand how well or badly the process is going. If they did it wrong, why not? If well done, again, why? What helped us to achieve such a result? Wrong conclusions or, even worse, their absence leads to the development of functionality that users do not need and unnecessary marketing activities.
Team change during development
Even in a situation where you do not agree with something, sometimes it is easier to pay a little extra to the developer to bring the project to the end and only then make a decision to change the team. Very often, new developers say what needs to be done again or rolled back to the previous development branch. Such a change of “horses in the crossing” is guaranteed to lead to an increase in the cost of development.
