How Long Is the Warranty? Free Maintenance Scope and Pricing
On the day a project passes acceptance, many clients read the warranty clause properly for the first time and find a single sentence offering one year of free maintenance. What that sentence covers, and what it does not, usually only becomes clear at the first argument over a change request.
Three common warranty lengths: three, six and twelve months
The length of a software warranty period should follow project complexity, not contract value. Three months suits small projects with a single function, few screens and no hardware, such as a form tool or a single-platform mini program. Problems surface quickly in such projects and three months is enough.
Six months suits a project with one complete business loop, including payment, orders and a back office that is actually operated. This is the most common length in our contracts, because it usually covers the first real peak season.
Twelve months suits projects with hardware integration, such as EV chargers, smart vending cabinets or access control, or projects deeply integrated with an existing ERP or finance system. Hardware and third-party interface faults often surface only after several months of live operation, so the warranty needs to span that period.
Longer is not automatically better. Every additional month of warranty adds roughly 1 to 1.5 percent of the contract value. Whether that sits inside the total price or is listed separately should be stated at signing, because a quote offering three years of warranty has usually priced it somewhere else.
What the warranty covers: defect repair, not new requirements
Free work during a software warranty period should be limited to defects: behaviour that does not match the agreed requirements document or prototype, or the program raising errors, crashing or producing incorrect data in the agreed environment.
The following are outside the warranty and need a change order: new features, changes to business process, visual redesign, switching to a different third-party provider, and adaptation forced by platform rule changes such as WeChat API updates or app store policy changes. Most warranty disputes we have handled trace back to this boundary being left unwritten. Putting it in the contract is far more effective than arguing later.
The start date is where a software warranty period most often goes wrong
Three formulations appear repeatedly: the date source code is delivered, the date the system goes live, or the date acceptance is signed. Use the signed acceptance date.
Starting from go-live creates a problem: if the client delays its own launch and only begins real usage months later, half the warranty is already gone. Starting from delivery is unfair to the client, because the code may be handed over well before launch and fault-fixing still counts. The signature date is the clearest point for both sides to verify.
How support is priced after the warranty ends
Two common models. The first is a percentage of contract value, typically 8 to 15 percent per year in this market, with the same coverage as the warranty and agreed response times. The second is billing by person-day, which suits projects where change frequency is unpredictable, at the current year's day rate.
Take a contract worth 100,000 RMB. Eight to fifteen percent is 8,000 to 15,000 RMB a year, roughly six to eleven person-days of a mid-level engineer annually. That is the benchmark for judging whether a maintenance quote is reasonable. If a quote sits well above that conversion, ask whether the coverage and response commitments are equivalent.
Four situations outside the warranty
First, problems arising after the client modifies the code itself or engages a third party to modify it. Second, failures of the server, network or cloud resources themselves, or the client relocating the environment without notice. Third, changes in third-party services, including payment channels, SMS gateways, mapping services and platform review rules. Fourth, requirement changes and new features.
List these four item by item in the contract and add one sentence: where the client requests assistance for these reasons, work is billed by person-day. With that sentence in place, neither side has to argue over whether a given issue counts as warranty work.
Five warranty clauses worth putting in the contract
Warranty period: twelve months from the date the acceptance confirmation is signed. Response times: for P1 outages, respond within two hours and provide a plan within eight; for P2 core-function degradation, respond within eight hours; for P3 general defects, respond within two working days. Free scope: only defects inconsistent with this project's requirements document, prototype and acceptance criteria. Exclusions: the four situations listed above. Post-warranty support: an annual percentage of contract value or person-day billing, under a separately signed maintenance agreement.
The value of a warranty clause is not its length but the clarity of its boundary. A one-year warranty with a precise boundary protects a client better than a vague three-year one.