

In this article, I’d like to share a few important thoughts and tips that will definitely help you avoid some moments that can negatively affect the development progress or even stop the entire project.
These tips I prepared include predicting various unpleasant moments, minimizing the number of change requests, and protecting yourself from starting the project over and over again.
We don’t always think about it that way, but all the logic of the application, site, or platform is actually displayed in the design. It may seem that the design and the backend are not closely interconnected, but in fact, the backend primarily refers to the application data. And this data is directly related to the design. However, it often happens that the output of real data to the front does not correspond with the template provided by the designer.
It means that we can have a very beautiful design, but since it was not agreed on with the development team, it would probably not meet the expectations at the end of the development stage. This is an especially important matter when the customer comes to us with an already existing design and only requires development.
In order to avoid issues like that, it is necessary to pay attention to the UX design, since all the logic of the future application and how it will work is based on the UX.
Before we start working on tasks (for example, developing a feature), we sit down to make sure everyone who’s involved understands the business value of the project. The point is to avoid mechanical execution at all costs, and instead acknowledge why we are doing this task. What result are we striving to achieve? This conversation is necessary as at the end of the project we don’t want to hear the client say: “Guys, this is not what I actually wanted.”
In addition, it would be nice to compose a terminology document for each project to learn more about the client’s business. It’s easy to start compiling it by answering the following questions:
Without answering these questions, it is possible to end up in a situation where developers will have to rewrite the code at one point.
Lack of business analysis and vague understanding of the main problem the product is going to solve create a lot of problems. Business analysis is an indispensable starting point for any project. Even if a client doesn’t want to initiate this conversion, you need to double down and seek answers to the following questions:
– Do users of the product have roles? If so, which ones?
– Will there be an integration of 3-rd party solutions? What kind pf solutions?
– What is the product’s monetization strategy? Does the product need ad placements?
– What content can users generate?
These are only a few questions. There are many more, of course. Don’t be shy and learn as much as you can to ensure the project’s success.
Before starting a project, it is impossible to take into account all the technical and logical limitations. Therefore, it is important to identify the “gray areas” early on and distinguish between logic and its direct implementation.
Lack of analysis at the beginning of the project can lead to technical limitations, and a lack of understanding of the business goal can lead to logical limitations. It’s better to tell the client in advance that there are things that you are not sure about and need to do detailed research, or conduct a proper Business Analysis, etc.
It is also important to consider the total cost of ownership, which includes the purchase price of a particular asset, plus operating costs over the asset’s lifespan. Thus, if we want to develop a project that involves storing a large amount of data, we need to understand where this data can be stored, and how much it will cost for our client in the future.
It often happens that during the development and/or design processes, tasks, prioritization, functionality, and risks alter; some features may be removed, some added. You need to record any changes within the project because they affect:
a) the intended plan for the project implementation;
b) project execution time;
c) cost.
So, you will protect both yourself and your client. Ideally, all meetings and calls should be recorded, and their summary review should be sent to the email of all responsible persons, stakeholders, including customers.
If your requirements change or a client offers new ideas, this should be documented. In this case, email is an ideal variant because no one can edit or erase the messages. As the saying goes, once it’s in writing, it’s permanent.
By the way, there are many other ways you can conveniently record the changes – for example, in Notion, Trello, Figma, etc. But as a rule, you use these tools to record already agreed changes.
I feel like I’m repeating myself, but it is extremely important to discuss everything. When you start the project, cover the following topics right away:
Moreover, it’s better to promise less, even if you realize that in the end, you can do much more. Don’t overpromise.
And never forget to put a buffer on the timeline, even if the risks are minimal. That way you’ll have time for mid-project and final checks.
Of course, there are more nuances and issues that you need to pay attention to when working on a particular project. However, the six points mentioned in this article will most likely help you to avoid the most common mistakes and make your project more efficient.
If you’d like to build a product and want to discuss our approach in person, reach out by filling out the form. You can also write an email to contact@ein-des-ein.com. We are happy to dive into your project idea and provide our help!
What kind of service are you interested in?
By continuing to browse or by clicking ‘Accept’, you agree to the storing of cookies on your device to enhance your site experience and for analytical purposes. To learn more about how we use cookies, please visit our Privacy policy (see Cookies Notice section).