A launch is not a finish line but a change of mode. The first weeks with real users always bring discoveries: a scenario nobody checked, a device with an unusual screen, data that was never in the test database. This is exactly the period a warranty is for.
But clients and contractors often mean different things by “warranty”. Below is where the line usually runs and what is worth agreeing on before launch.
What a warranty is
A warranty is the contractor’s commitment to fix, free of charge, bugs in the work they built and handed over. If a feature described in the requirements and accepted at acceptance stops working or works differently from the description, that is a warranty case.
Our work comes with a 6-month warranty after launch. That is usually long enough for the product to go through all its typical cycles: daily, monthly and reporting periods.
What the warranty covers
Typical warranty cases:
- a feature does not work as described in the requirements or the specification;
- a logic error — a wrong calculation, a wrong status, a lost notification;
- a failure in a scenario that was in the requirements but only showed up on real data;
- a performance problem within the load agreed in advance.
The main test is whether the behaviour was described and accepted. So the more detailed the requirements and acceptance scenarios, the easier it is later to tell a bug from a new task.
What is usually not covered
This is where misunderstandings happen most. As a rule, a warranty does not cover:
- new features and enhancements. “Add a filter to the report” is not a bug but product development, even if the idea came up in the first week after launch;
- changes in requirements. If a process in the company changes, the system has to change with it, but that is new work;
- changes in other systems. An external service releases a new API version or changes its rules — the integration needs updating, and that is ongoing support;
- updates for new versions of iOS and Android and new app store requirements;
- infrastructure problems — server or cloud outages, unless they are caused by a bug in the code;
- the effects of changes made by others — for example, by your team or another contractor.
The exact terms are set in the contract. Ideally, it also describes how to report an issue and how quickly it is handled.
How to report a bug so it gets fixed quickly
How fast a bug is fixed depends a lot on how clearly it is described. “Nothing works” takes several days of back-and-forth. A good report includes:
- what you did — the steps that led to the error, in order;
- what you expected and what actually happened;
- where it happened — web or app, browser, phone model, app version;
- when — the date and approximate time, so the team can find it in the logs;
- which user — different roles have different rights and data;
- a screenshot or screen recording, if the error is visible.
If the error stops many people from working — a payment does not go through, say, or the main screen does not open — say so right away, in the first line. Such reports are handled first.
Support and development after the warranty
A product does not freeze after launch. Even without bugs, it needs:
- monitoring of stability and a response to failures;
- updates to dependencies and libraries, including for security;
- updates to integrations when external systems change;
- releases for new iOS and Android versions;
- new features based on analytics and user feedback.
This is technical support and product development. It is convenient to plan them the same way as development: in iterations, with a clear task list and demos. They are paid separately — by plan or task by task.
Handing over the project
A good project can be handed over — to your own team or to another contractor — without months of onboarding. For that, after launch you should have:
- the source code and access to the repository;
- access to servers, cloud, external services and app stores, registered to your company;
- documentation — architecture, API, deployment procedure;
- a description of the integrations — which systems the product is linked to and how the exchange works;
- a list of known limitations and plans that did not make it into the current version.
We prepare documentation on architecture, API and deployment so that the system can be developed further by your team or by any other contractor. Even if you plan to work with one team for a long time, being ready for a handover is a sign of a healthy project.
What to discuss before launch
To keep the warranty and support from becoming a source of disputes, agree in advance on:
- How long the warranty lasts and when it starts.
- What counts as a bug and what counts as an enhancement — rely on the requirements and acceptance scenarios.
- How issues are reported and how quickly they are handled.
- What happens after the warranty: planned support, task-by-task work or your own team.
- What is handed over to you — code, access, documentation — and when.
In short
The warranty covers bugs in the delivered work. Product development, changes in external systems and new requirements are support. The line between them follows the requirements and the acceptance, so their clarity matters not only at the start but also after launch.
More about what our work includes is on the services page and in the description of custom software development.
A warranty is not insurance against everything. It is a promise that what was built works the way it was agreed. Everything else the product gets in its next version.
