You buy a website... and then what?
When buying a car we ask about the warranty. When buying electronic equipment, we want to know how the service looks. When renovating a house, we expect the contractor to take responsibility for their work.
And when ordering a website or application?
Very often only one question is asked: "When will it be ready?"
That is understandable. Everyone wants to launch their project as soon as possible. The problem is that the deployment day is not the end of the project. It is the moment when the solution starts working in a real environment.
And it is precisely then that the warranty becomes most important.
What actually is a software warranty?
Many people mistakenly assume that a warranty means free addition of new features. That is not the case.
A warranty covers the correctness of the solution's operation in accordance with the agreed project scope.
If after deployment a bug emerges that results from the design or programming process, the contractor should fix it according to the warranty terms. It is responsibility for the quality of their own work. Not for changing business requirements.
Warranty vs system development — they are not the same
This is a very important distinction.
For example: after half a year the company wants to add a booking module. This is not a bug fix — it is system development.
The same will apply to integration with a new ERP system, adding more payment methods or redesigning the admin panel — these are new functionalities.
However, if the contact form stops working because of a bug in the code created during the project, we are already dealing with a warranty issue.
What should a good warranty include?
There is no single mandatory standard, but it is worth checking whether the contractor clearly specifies:
- what is covered by the warranty,
- how to report bugs,
- what the response time is,
- how the issue verification process looks,
- whether fixes are performed at no additional cost,
- what situations are not covered by the warranty.
The more transparent the rules, the fewer misunderstandings in the future.
Why warranty length doesn't tell the whole story
A one-year warranty is not always worse than a three-year one. A three-year warranty also does not always mean the highest quality.
The most important question is: Will the contractor actually be available when a problem arises?
Even the longest warranty means little if after a few months it is difficult to contact the contractor. Therefore, it is worth paying attention not only to the clause in the contract, but also to the company's experience, its history, the way it communicates and its approach to clients.
Most common post-deployment situations
After project launch, various scenarios may occur.
For example:
- users use the system in a way that was not anticipated earlier,
- new browser versions appear,
- external APIs change,
- a payment operator updates their solutions,
- the company wants to expand the system with additional modules.
Not all of these situations are execution faults. That's why it's important to distinguish between warranty, technical support and project development.
A warranty is also a signal of trust
A long warranty also says something about the contractor. It shows that they take responsibility for the prepared solution and do not end the cooperation on the publication day. This is especially important for custom systems, online stores and applications that often evolve over many years.
How does it look at Web24?
At Web24 we start from the assumption that project deployment does not end the cooperation.
Therefore, for the websites, online stores and applications we create we provide a 3-year warranty for the work we have delivered.
This does not mean that for three years we will expand the project with new functionalities for free. It does mean that we take responsibility for the quality of what we have created.
Because we believe that a good software house should be a partner even after deployment is completed.
Summary
When choosing a contractor, it is worth asking not only about price, delivery time or technology.
It is also worth asking:
- What does the warranty look like?
- What does it cover?
- How are problems reported?
- Does the company provide post-deployment support?
- How long does it take responsibility for its solution?
These are questions that often determine the quality of cooperation in the following years.
Because well-written code is valuable.
But equally important is the certainty that you won't be left alone with it after deployment.
