Software warranty and aftercare
After delivery, software mainly needs to run reliably. That is why a project with us does not stop the moment something goes live. We define how we handle bugs from the initial development and how aftercare connects to that in a logical way.
Fixing bugs from the initial development free of charge
A warranty period with clear boundaries
Aftercare arranged directly after go-live
After the first delivery
Bug fixes after delivery
In project proposals, we include a warranty period in which bugs or technical issues that trace back to the original development are fixed free of charge. For business-critical software, that is not a luxury. Right after go-live, you want to know that issues will not be left hanging because the project would formally already be finished.
At the same time, that warranty is deliberately bounded. It covers restoring what was built within the agreed Glossary · In briefscopeScope defines the boundaries of a project or assignment: which goals, activities and results are included and which are excluded.Read more, not a second stream of new wishes, extra modules, or changed requirements. That keeps it clear even after delivery what counts as recovery work and what counts as ongoing development.
How we draw the line
From bug fixing to aftercare
Problems that can be traced back to the initial development are fixed free of charge within the agreed warranty period.
We explicitly distinguish between recovery work and new functionality. That prevents debate and keeps priorities clean.
After the first delivery, we align on what support still makes sense, for example through maintenance or SLA agreements that follow the warranty period.
We handle issues on substance, determine the cause, fix it, and verify that the software again does what was agreed.
Aftercare belongs to the project itself. You do not want to start improvising only when users depend on the software for the first time.
Start with the base
Warranty on issues from the first build
Problems that can be traced back to the initial development are fixed free of charge within the agreed warranty period.
Why this matters
Support during the first months
Daily use can reveal errors that were missed during testing, for example in exceptional situations or handovers between teams. That is why we agree upfront how we will follow up on reports after go-live and which errors the warranty covers.
That is why we do not treat software warranty and aftercare as a footnote. It belongs to the same line as Glossary · In briefquality assuranceQuality assurance (QA) is the set of planned, systematic measures a team uses to help software meet agreed quality requirements.Read more, release management, and Glossary · In briefmonitoringMonitoring systematically tracks software, infrastructure or processes through measurements and checks. Deviations can trigger alerts so an administrator can investigate.Read more: making sure the system is not only built, but also gets through the first usage phase responsibly.
What this gives you
A clear warranty period after delivery
Free recovery of bugs from the initial development
A clear line between recovery work and new work
A logical transition from go-live to aftercare
Frequently asked questions
Bugs and technical issues that trace back to the original development and fall within the agreed scope.
No. Aftercare can flow into support or ongoing development, but new wishes stay a separate decision with their own priority and impact.
We record the precise wording per assignment. In our project proposals, we work from a fixed warranty period after delivery, followed by agreements about aftercare.
After the warranty period, support can continue through maintenance or SLA agreements, so follow-up, support, and continuity do not have to be reinvented.
Is your question not listed here?
Get in touch