— 7 reading minutes
Whenever someone contacts us with a new project, one of the first things we do is review together the different phases in which we will divide the work. We do this because, although sometimes it is not said directly, we all have in mind a schedule and a budget that we would like to stick to, when we get into a custom development. Besides, it is something that we do not usually do, I mean, in the Real World™️ we buy few custom things, we are not used to ordering things handcrafted for us, so it is normal that it is difficult to get an idea of what it is going to cost, both in money and time.
1.Understand the motivation, the problem to be solved or new idea to be developed.
When someone contacts us, it is because they either have a problem to solve or a new idea to develop. It is very important for us to understand the motivation behind starting the development, because motivation can affect the approach and objectives of the project, as well as its success.
On the one hand, it obviously helps us to define the objectives to be achieved: If we know why someone wants to make an application or website, we can clearly define the project and ensure that the solution we propose adequately addresses their problems or needs. Also, on some occasions, it is important to understand why now and not before, if it is a new problem or, although it was known, there are other circumstances and characteristics that allow it to be addressed now.
It also prevents misunderstandings: a bit the opposite of the above, if we do not understand the motivation of the person who is asking us for the project, there may be misunderstandings that cause errors and delays, which can affect the quality and delivery of the project.
Once the motivation is understood, we want to understand the problem to be solved or the new idea to be developed. What needs does the user have that are not currently being met? What are the limitations that need to be overcome? Understanding the problem well allows the scope of development to be clearly defined.
Finally, part of the process of understanding the problem or domain of the application well is to analyse the competition, if there is any, if the client has any competition references with which they are comparing themselves, for example. This will help us to see with the client what concepts they like about their competition, in what aspects they think they could do better, etc.
Definition of requirements: Once the problem has been defined and the competition studied, the application requirements must be defined. What functionalities must the application have? What are the user requirements? What technologies will be used? All of this must be clearly established in the planning phase.
2. Requirements analysis
Since we always use agile methodologies, a common mistake is to think that it is not necessary to do a requirements analysis before starting the project, that we can simply start by defining "the first sprint" and continue from there, but this would be a mistake. Actually, even if using agile methodologies we define a series of short development cycles, it is important to analyze the complete requirements, as a whole, of a new web application, because it is essential to understand the final needs and expectations that our users and clients will have and, because when it comes to establishing priorities and what to include or not in the first cycles, it is important to have a complete vision.
Requirements may change with each sprint as more information is obtained and priorities are adjusted, but having a clear understanding of the initial requirements can help establish a clear vision and objectives for the project. In addition, a proper analysis of the requirements can help ensure that the team is working on the features and functionalities that really matter to the client.
3. Architecture design
Defining the architecture of a web application is crucial because it helps establish a solid foundation for development. It is similar to having a blueprint for building a house; without it, the project is likely to fail or be inefficient.
By defining the architecture, the components and structure of the application can be established, it ensures that the development of the application is coherent and scalable, allowing new requirements to be easily incorporated, and it makes it easier to budget the cost of the infrastructure on which the application will be built for the client.
4. Visual design, user experience (UX) and prototyping
In this phase, we create a visual design of the web application, which includes the user interface, navigation flow, and information structure. Here we focus on creating an interface that is attractive, intuitive, and easy to use for end users.
We will work on the visual design of the application, including choosing colors, typography, images, icons, and other graphic elements to be used in the interface, which may have been previously developed by the client, or may need to be developed from scratch. We also work on the user experience (UX), which means designing the way users will interact with the application.
Additionally, in this phase we usually make prototypes of the application, which are interactive representations of the application's interface and functionality, which make it easier for us to see with the client how the application will work before fully building it. This makes it easier for us to make improvements and adjustments to the interface before the development phase begins.
5. Application Development
We really like programming, eh, and it took us 5 phases to get here. But in reality, the more time we spend on the previous phases, the fewer problems we will have in this and the following ones, so they are really very important. At this point we write the code for the web application. Here we will dedicate as many development cycles as necessary to have an initial version, carrying out all the tests and error corrections necessary to ensure that the application meets the requirements we had previously defined.
Books have been written to see what an "initial version" would be, perhaps you have heard of a Minimum Viable Product, or things like that, but without going into great definitions, let's say that here we try to polish everything until we reduce what is going to be done to the minimum possible expression, which really adds value and is worth being delivered and enjoyed by the client. This, of course, will depend a lot on each case, but in general we maximize what is not done in this initial version and leave it for later.
Between cycles, the requirements may change, because in the end we know that we live in a changing world and that what could have been left for later a month ago has now turned out to be a fundamental part of the project, but in the initial version we try to reduce these changes to a minimum.
6. Deployment
The deployment phase is when we deliver the code to the different execution environments we have. Normally, we have an initial development environment, in which all the different changes we have been developing locally are integrated, a Staging or pre-production environment, in which the client can validate the different developments, and the Production environment, which would be the final environment, in which the final clients can use the application.
Due to our way of developing, deploying artifacts, the code delivered in the different environments is the same. This minimizes possible errors between deployments in one environment or another, since we always deliver the same thing. The only thing that changes between these deployments are some configuration variables that depend on the environment. In addition to guaranteeing that we always deliver the same thing, the privacy of certain information is ensured, which, instead of going in the code repository, goes in these configuration variables per environment.
Although we have placed this deployment phase at the end, to explain how it works, it is important to understand that in a development based on agile methodologies, it is normal to deploy with a certain frequency, as there are enough tasks that add value.
7. Evolutionary, maintenance of the application.
