When planning the deployment of any application for production, it is important to always consider at least the following 5 business processes / Value stream in one form or another:

application development process

application configuration process

the process of setting up and configuring servers (or other runtime environments)

the process of setting up and configuring the build and deployment process itself

the process of setting up and configuring auxiliary services (for example, monitoring, backups, etc.), here I will write databases, caches, queues, etc.

how to build an infrastructure for small projects when the team does not yet have the competencies of an admin / devops engineer, neither the manager or programmers, nor in the form of a dedicated person.

What to choose in this case - dedicated servers, cloud or Kubernetes? I will not make any technological recommendations now, but I will describe what you need to pay attention to organizationally so that you can make such a choice.

Impact of the software concept on customer expectations

If you are working on an investment project, then the concept of your software development project allows you to build a business development strategy. It allows you to find new consumers for your product or service. No top manager in their right mind would dig into the code or architecture of a system. You won't get a single customer by talking about clean code or your team's development methodology. But as soon as you show a colorful picture from your concept, everything starts moving in the right direction. Your product vision becomes the vision of your partners, customers and even competitors. But this will only work if the concept is strictly followed when designing your system.

Breathe the spirit of the concept into your project, take care of its health and never lose it.

The project team is very rarely involved by the customer at the stage of formulating goals and objectives. More often, the performer receives wording just before the competition itself, which does not give much time for maneuvering. At the same time, as can be seen from the above example, the customer does not always show sufficient attention to the correctness of the formulation of the goals and objectives of the project. Therefore, when starting to develop a concept, the contractor must voluntarily or involuntarily review the picture of the future product that the customer is trying to show him. At least in order to get acquainted with the expectations of the customer.

The concept is magic. If the architecture is the skeleton of a project, then the concept is its spirit. There is no concept, and the project leaves a lifeless body, from which it soon begins to stink. But when it is, the project develops, and the better the concept is executed, the healthier the project will be, and the more confident and successful the members of the project team will be.

But it is not enough to create a concept in a software development project and coordinate it with the customer. It is necessary that all development of a software system is carried out in full accordance with the accepted concept. No one should be allowed to violate it. Yes, it can and should be corrected if there are serious reasons. But the reasons must be serious. And the decision should be made at the highest level and always agreed with the customer.

Remember: if there is no concept, the project is dead. If some part of the project is not supported by the concept, this part of the project either dies or infects other parts of the project, and then the whole project dies. If the concept is there, but not fully implemented, then the project will stall every now and then and eventually go beyond the acceptable time frame and budget. If the concept of the team is different from the vision that was agreed with the customer, then you are not making the system that you were asked to do. I have never seen any compromises in these statements.