Updates are used for correct operation of the system, having the current version of the system and securing it by getting rid of security gaps, its development and improvement. The systems we produce have a guarantee, but it does not cover system defects that are not updated, have been updated by the customer or have been changed unauthorized by the Contractor.

Solutions based on ready-made management systems such as WordPress, Prestashop are extended by modules and templates from external suppliers who may delay updating their products, and in extreme cases abandon the support. In such a situation, updating the system may cause errors in the operation of the website or its individual parts. Occasionally, changes made by the user are lost after updating the system, modules or template. Therefore, we make backup copies, because thanks to it we can restore the system to full functionality, so that users can use the website while the errors are being repaired.

Depending on the solution at your disposal, the process of issuing updates by groups / producers is different. In the case of solutions such as WordPress, updates may appear even every day. Our experience shows that systematic updates once a month are the most reasonable solution, because even if system vulnerabilities appear, the period of one month is usually too short for even known vulnerabilities to be used on a large scale. In the case of constant cooperation when detecting a “critical” vulnerability in the system, we update immediately.

Because they can cause errors in the operation of the website or its individual parts. Users may also lose their changes. For example, in October 2020 there was a situation when the automatic update of WordPress updated the website to the “alpha” version from almost 8 years ago – the systems of many million users stopped working because of the turned on automatic updates. We recommend entrusting updates to specialists who do it manually.

Yes, it is not possible for us to predict how important the updates are and how many will unfortunately come out. However, before we make more extensive than the one we agreed, we will inform you about the services and we will not do anything without your consent. How often does it happen? From our 6 years of work observations such situations have appeared twice so it is a very rare problem and concerns the most important and the largest applications.

Software developers work with a strictly defined schedule and in time slots based on agreed hourly estimates.If you have purchased a package of hours, software developers have blocked them in their monthly schedules and are at your disposal. We do not accept more work than our schedule allows us, so if we have blocked hours for you, we do not accept other orders. For this reason, unused hours do not carry over to the next month and are not added up.

We often receive orders to change key functionality or remove specific materials from the website. Some of the changes are irreversible, so we must have a clear message in writing, because in the event of a misunderstanding, we have grounds to decide whether we have worked within the scope of the order or whether there has been an error on our side. E-mail correspondence protects both sides against possible unpleasant disputes. The second reason is simply the order and the way the work is done. By receiving e-mail guidelines, the software developer can return to the task during his working hours, which often do not coincide with your working hours. In addition, most of the team are software developers, the telephone service of the office is carried out by one person who is not always able to answer the phone, because he is currently conducting a meeting with another client or a telephone conversation. It is much easier to handle e-mail correspondence in the order of its receipt and catch emergency situations, than to conduct a large number of conversations, and only then write down the scope of ordered tasks and queue with programmers. This way of working allows us to keep the costs of order execution affordable.

Because it saves your money and minimizes the risk of error. A software developer who knows your system is able to perform the commissioned work in a shorter time than a software developer who would have to learn its specifics first and then start working. Remember, the billing of services takes place in hours, so the faster the software developer completes the order, the less you will pay for them or the smaller pool of your hours will be used. In addition, the software developer who takes care of your project knows it well enough that he knows what he can do without any problems, and which of the actions may be wrong, which module may come into conflict with another, which functionalities are overwritten, what are the main assumptions of the project, etc.

Because paid modules and licenses are provided by external developers and it is impossible to predict their preservation and cost estimation for the future. The price range of external developers is so different and dynamically changing that we are unable to calculate the average or estimate costs. Additionally, we do not see the need to increase prices just because a paid module or license may be needed in the future.

In order to answer your query or to perform the commissioned work, the software developer must log into your system and check if he has such a possibility, what are the options, look for the appropriate module from external suppliers, etc. He behaves in the same way when you ask him a question via e-mail or commission work to be done. If the software developer spends an hour / half an hour on the phone with you, it means that he has done the work for you. Of course, we do not settle small inquiries such as “a few minutes” of his work, but if such calls for several minutes are made several times a day, it will already be counted as an hour. We settle it this way because every time you call, you distract the software developer from another project, the software developer has to log into your project, answer queries, etc., and time is lost. If this happens several times, it adds up to an hour of his working time, because he has done the work physically.

Working continuously and systematically, we are able to keep costs affordable for you, because we know your project and we do not forget its specifics, because we are there at least once a month. If you come back to us, e.g. every three months, we have no chance of remembering the characteristics of your system and its assumptions, then additional hours are needed for re-implementation, which generates higher costs. The second reason for maintaining service continuity is that WordPress is an open source system and we have no influence on how serious and how many updates are released in a given period. It may turn out that for three months the updates will be so-called minor, i.e. they will not be significant for the main functionalities, and it may be that the updates will be so-called major, i.e. crucial for the security and proper functioning of the system. If you come to us too late, someone may take advantage of a security hole in your system earlier and repair the damage they caused may be even higher than the cost of a new page, or it may turn out that the transition between versions is too large and we can no longer perform the update while maintaining the correct operation of the system. The cases we are writing about are extreme, but we have already had such situations. Therefore, we recommend continuity of service, because it is better to be safe and calm than regret it later.

Because after a longer period of time, we will forget the specifics and characteristics of your system and will need additional working hours for re-implementation, and additional working hours are associated with additional costs. Also, if you wait too long, your website may stop working properly during this time or have security gaps which, if used, may generate additional costs of system repair.

Unfortunately yes. Information systems have this to themselves that they are interdependent on other systems and many external factors. The easiest way to explain it is to use life insurance as an example – we are not able to insure ourselves against all diseases and situations, but we can significantly reduce the risk and protect ourselves against difficult situations. It is the same in the case of the system maintenance service – the risk of a failure not attributable to either party exists, but it is much lower on a system that is systematically supported and due to the constant support, the software developer’s response will be the fastest possible. If, for example, there is an attack on the website, the developer can react immediately and knowing the system well, he will be able to take appropriate action. For example, if Instagram changes its API (which takes place at least once a year) and the Instagram carousel stops showing on the page, the developer changes the linking system and adapts it to the new API, and the carousel shows up again. We have no influence on the behavior of third parties on which the functioning of the system depends, but we have an influence on how we react.