Last updated: September 2026
Without a warranty, software is delivered and then becomes your problem. A defect found three months after launch is a new engagement, at a new price, often with a team that has never seen the code. We contract the other way round: what we build stays our responsibility for the warranty term, one year by default and up to three.
What the warranty is
A warranty is a promise about defects. If the system we delivered does not do what we agreed it would do, we fix it at no charge for the agreed term. Each part of that sentence carries weight:
- Against what was agreed. The warranty is measured against the agreed scope, not against what anyone later wished the system did. That is why a precise scope protects you as much as it protects us.
- At no charge. The warranty is included in the project price. A warranty that bills for the fix is a support contract under another name.
- For a term set before the work starts. One year by default, up to three, agreed with you before the project starts and stated in the contract.
Which work carries it
Every development project we deliver carries the warranty, including the customisation we build on top of one of our platforms. Audits, maintenance and hosting are services rather than development projects, and their terms are set in their own agreements. A platform partnership with an agency is not a project in itself; the development work done within it is, and carries the warranty like any other.
The work is done by the same team that built the system. That is most of why the warranty is affordable to offer and useful to hold: nobody has to learn the codebase before they can fix it.
What is covered
- Defects in what we built. The system does not behave as agreed: a form rejects valid input, a report totals incorrectly, a workflow stalls in a state it should pass through.
- Security fixes. A vulnerability in the code we wrote is patched, and the security releases of Drupal core and contributed modules are applied while the warranty runs.
- Performance defects. Something we built is slow in a way that was not part of the agreed behaviour.
- Compatibility with Drupal core minor releases. Core releases arrive on their own schedule; the code we wrote keeps working with them.
What is not covered
- New features. If the system does what was agreed and you now want it to do something else, that is a change, not a defect.
- Changes in third-party services. A payment gateway retires an API version, or an identity provider changes its token format. We did not cause it, and adapting to it is work.
- Changes we did not make. You own the source and may change it freely, and we will still help. A change we did not make is not a defect we introduced, so it sits outside the warranty.
- Infrastructure outside our control. A data centre outage is not a software defect.
- Code we did not write. On a system someone else built, what we offer is maintenance, and a warranty on whatever we build for it afterwards.
Defect or change: the cause decides
Most reports are clearly one or the other. For the ones in between, the cause is established before anyone talks about cost. The same symptom can land in different places:
| Cause | How it is handled |
|---|---|
| The code we wrote does not work with a Drupal core minor release | Warranty Fixed at no charge |
| The payment provider changed its API | Not warranty Maintenance work, or quoted as a change: nobody warrants another company's roadmap |
| Someone edited the code directly on the server | Not warranty We say so, and quote the repair |
Who holds the warranty
The warranty belongs to the party that signs the project with us. When you contract with us directly, that is your organisation. When an agency brings us in, whether we work under its name or appear as its subcontractor, the warranty belongs to the agency, as the party that signs with us. What the agency promises its own client is the agency's to set. The terms we agree with agencies are on partners.
How quickly a report is answered
| Severity | Target first response |
|---|---|
| Critical | 4 hours |
| High priority | 1 business day |
| Normal | 3 business days |
These are targets for our first response, not resolution times: acknowledgement, triage and a view on what is happening. Nobody can honestly promise a resolution time for a defect that has not been diagnosed. Operating hours, time zone, severity definitions, escalation path and any resolution commitments are set out in the support agreement for your system. Out-of-hours cover is not part of the default: it is an optional, priced addition to that agreement.
Warranty, maintenance and an SLA
Worth separating, because they are often confused. The warranty covers defects in what we built, and applying Drupal core and contributed module security releases, at no charge, for the agreed term. Maintenance is a separate ongoing arrangement covering updates, monitoring and changes, including on systems we did not build. An SLA is neither: it is a set of measurable commitments attached to one of the other two.
| Question | Warranty | Maintenance | SLA |
|---|---|---|---|
| What it covers | Defects in what we built, and the security releases of Drupal core and contributed modules while it runs | Keeping a running site healthy: updates, dependencies, backups, monitoring and small changes | Measurable commitments: response times by severity, availability targets, escalation |
| How it is paid | Comes with a development project, nothing extra | A monthly agreement | Priced for what it obliges us to staff |
| How long | 1 year by default, up to 3 years | While the agreement runs | As written in the agreement |
| A site we did not build | Not covered | Covered, after an audit | Agreed in writing |
The longer argument is in Warranty, maintenance and SLA are three different things, and the questions worth asking any supplier about a warranty are in What a software development warranty actually covers. Maintenance itself is Drupal maintenance and support.
When the term ends
A warranty is a promise from a company. What does not depend on anyone's goodwill is the code: you hold the repository from the first commit, documented for a developer who has never met us, so a defect found after the term is a job any Drupal team can take on. Why we contract that way is set out in you own what we build.
After the term, security releases and upkeep continue under a maintenance agreement if you want one. The warranty does not depend on you buying it.
Questions we get asked
- Is the warranty billed separately?
No. It is included in the project price. If a proposal quotes warranty and maintenance on one line, ask which part of the fee is the warranty: the answer should be none of it.
- Does it include Drupal security releases?
Yes. While the warranty runs, the security releases of Drupal core and contributed modules are applied as part of it. After the term, applying them is part of a maintenance agreement.
- Can we change the code ourselves during the warranty?
Yes. You own the source and may change it freely. What you change sits outside the warranty, because it is not a defect we introduced; everything else we built stays covered.
- Does the warranty cover a site someone else built?
No. A warranty can only follow code the warranting party wrote. On a site someone else built we offer maintenance, after an audit, and a warranty on whatever we build for it afterwards.
- Who holds the warranty when an agency hires you?
The agency, as the party that signs with us: one year by default, up to three. What it promises its own client is its own to set.
Contact
For warranty claims, contact us at [email protected].
See it working before you commit
We build a working prototype first, so you decide against something real.