Why is My Software Warranty Only 30 Days?

Few things change faster than the world of technology – and it’s no different when we’re talking about the subsection of digital products. The moment you launch a new website, web app, or mobile app for your organization, changes to the software infrastructure around it are already well underway, or even updating that same moment.

Those constant updates and changing variables are one of the big reasons you need to practice good digital hygiene for your products – and one of the big areas people neglect when launching new technology. They’re also the underlying reason the software warranty or guarantee in the contract for your new digital product is often 30 days.

Only 30 days?! Yep. Often, this whole subject is missed or avoided by technology consultants. Instead of avoiding it, let’s talk about why that is.

Industry Standards & Software Contract Warranties

The industry standard for functionality guarantees / software warranty periods is 30 days. It doesn’t mean on day 31 nothing is going to work, like that toaster you bought last year – it is highly likely your new website or app will continue to function properly for months – it just means that the functionality of new software, and the constantly changing technology around it, becomes impossible to guarantee for no additional cost past that point. The risk to the software development firm just becomes way too high as there are way too many things out of the firm’s control.

It doesn’t mean you won’t find 45 day, 60 day, or even longer warranties (I touch on longer warranties below). It just means the generally accepted default clause accounts for 30 days of bug-free functionality as a part of your new product launch. This is just one clause of many that are important to understand in your software development contract.

The Changing Variables That Affect Software Functionality

At first glance, there might not seem to be too many moving parts to your new application. There’s the interface, the back-end, the server – that’s about it, right?

Not quite. As we begin to dig, it becomes clear that the combination of tools, frameworks, and technology that allow for cost-effective, expedited development of your website or app creates a near infinite amount of combinations – any of which could conflict. And that’s only the technology powering the app; there is still the whole end-user side of it (their devices, OS, and the like).

Here’s an example. Let’s say you hire a firm to launch a new, mobile-first web application for your organization that allows users to sign up, create a profile, discover and connect with other users on the platform – like the one we built for Electricity Human Resources Canada, Mentor Junction.

Here is a non-comprehensive list of technology that powers, and interacts with, a web application like that:

1. Laravel
2. Livewire
3. PHP
4. Alpine.js
5. Nginx
6. JSDelivr
7. Lodash
8. Axios
9. jQuery
10. Select2
11. Moment.js
12. Google Tag Manager
13. Google Chrome (MacOS, iOS, Windows, Android)
14. Safari (MacOS, iOS)
15. Firefox (MacOS, iOS, Windows, Android)
16. Plus individual devices themselves: iMacs, Chromebooks, all the various smartphones, and the like.

That’s a lot of moving parts. And all of those moving parts, like any modern and well-adopted technology, are actively developed. Meaning, the team who works on those products are continually releasing versions of the software that either improve it or fix bugs (read more on software versioning and how you can use it to handle your project post-launch). You want actively developed technology, but it can also lead to issues – which is what puts the ceiling on your software warranty.

What Actively Developed Software Means For Functionality

If your new digital product wasn’t using actively developed technology, it would inevitably break down over time, or face the increasing likelihood of an application security breach. However, with each version release to any of the stack your platform runs on comes the risk of incompatibilities.

For instance, using the list above, if Google Chrome releases an update, maybe it doesn’t play nicely with Livewire, the framework used to build the application’s interface. Or maybe a critical issue is discovered in the version of PHP your server is running, and if you don’t update it, your user data is at risk.

These are just two of many potential conflicts that arise out of myriad possibilities. Chrome alone has released 8 versions in the previous 8 months.  And that is the reason your warranty is for 30 days. There are too many variables that lie out of the software developer’s control that can affect the functionality of your new platform.

Can I Negotiate a Longer Warranty for My Software?

Sure. I cover this in A Buyer’s Primer to Software Development Contracts: What to Look For and Why:

If, for whatever reason, you need to negotiate a longer guarantee period, that’s fine – just understand that your costs will go up as a result. That’s because of the general rule that if you want to take risk off your plate, which is what an extended guarantee does, you have to pay for it.

It’s really no different than extending the guarantee or warranty for anything else you buy. You’re paying to offload risk, and for peace of mind. There’s no right or wrong answer here – it’s about what feels best for both your organization, and your software development partner.

Find the Terms That Work for Everyone

At the end of the day, every digital product firm wishes we could guarantee the products we launch in perpetuity. Unfortunately, it’s just not a realistic proposition. That’s why we build our client’s websites, web apps, and mobile apps on tried and true software – to limit potential conflicts – and do so in an agile fashion. That approach, in accordance with a 30-day software guarantee and a mutually agreeable software SLA is the combination we use, and the one I’d recommend you look for in your next development partner. It’s a set of ingredients that combine in a recipe for long-term, jointly beneficial business partnership.