What is the right strategy to support a project after it has been delivered?

Question

Freelance

Hello!
Faced the problem of choosing a strategy for further support of the product. I am placing an order for a catalog site and thought that I need to somehow set a price for the customer for subsequent edits (after delivery) and, in particular, possible bugs.
As for edits - you can just negotiate based on the amount of work, but what about bugs?
Now I'm thinking in the direction of such a decision:
1. Set a certain period, if during this period the customer finds a bug - I do it under the "guarantee".
2. If later than the deadline - do you need to pay based on the hours spent? Or an amount of N rubles for X hours per month?
I would like to know how experienced freelancers solve such a problem and what strategy is most appropriate.

Answer 1

Set a certain period, if during this period the customer finds a bug - I do it under the "guarantee".

Support, I do it myself. You just need to immediately agree that there is a bug, and that there is a new Wishlist of the customer.
Here you have to look at the situation. If you take a fix for a month, then you can be downloaded so that you will remain in the red. Completion with payment for the hours spent is good, but they may not be regular. I'm for the option of paying by actual hours.

Answer 2

1. I set a deadline. Although there have been cases in the world that bugs are found after N number of years. )
2. I take payment by the hour. If something is very simple and fast, I do it for free.

Answer 3

1. The client accepted the site , everything that follows is within the framework of technical support and improvements support is worth the price. amounts per month, different tariff plans are possible
3. Improvements are carried out for a fee, provided that there is technical support for the project

Answer 4

I fix bugs for free for life, but I need a 100% guarantee that this is my mistake. To do this, I tear up my latest version at home and see if there is such a bug, if there is, I correct it for free, if not, or if there is no way to check it for money.

Answer 5

After the end of the project, you need to fix the current state of the project, i.e. sign the acceptance document. If the project develops further (by your forces or by the customer), then you need to make a document in which all the agreements on the project are written down. Also, this document should describe warranty and non-warranty cases, as well as cases when you refuse to support this project (for example, the customer introduced something into the project that was not included in the architecture, and thus may disrupt the operation of the program).
Regarding bugs, the practice is usually as follows: before the project is delivered, the customer must provide a set of successfully passed functional tests (and in general it is a great option if these tests are run daily and there is reporting on these tests (which passed, which did not and why)). If the customer finds a bug (and usually it happens), the main thing here is to find the cause of this bug, i.e. it is possible that some kind of crooked user launched the application in a wrong way, or with the wrong set of parameters or something else. If the fault is on the customer's side (let's say the application was launched in a wrong way), then this is not considered a bug and you can simply give recommendations on how to launch the application.
If the logic for particular cases is incorrectly implemented, then there is an obvious bug. Usually, for such purposes, an estimate is made of how much time it will take to fix a given bug (usually man-hours). And then comes the agreement. After agreement, you receive the agreed amount of time and payment.