Warranty vs Maintenance: Scope Boundaries, a Four-Tier Pricing Formula, and a 12-Point Vendor Scorecard

An industrial parts trading company spent NT$850,000 on a quoting and order management system. On day 47 after launch, the purchasing manager filed 31 tickets at once with a single note attached: "These are all under warranty, right?" The vendor replied that 9 were genuine defects they would fix, and 22 were new requirements that needed separate quotes. The client's response was blunt: "We went live six weeks ago and you already want more money?"

I was later brought in as a third party to review those 31 tickets. Reading the contract took four minutes, because everything about the post-launch period fit into one sentence: "This project includes a three-month warranty." No definition of what the warranty covered, what it excluded, what counted as a late report, or what happened after month three. That one sentence produced 19 working days of argument. The client eventually paid NT$140,000 to close it out, and the relationship ended there.

Myths worth breaking

Myth 1: "The warranty period is just a free maintenance period"

Reality: These are two different things. Warranty fixes what was supposed to be correct but was not. Maintenance keeps what is already correct from breaking. A payment API version change, a browser behaviour change, a forced OS upgrade — none of these are the vendor's fault, and all of them can break your system. Folding them into warranty means asking a vendor to absorb unbounded external risk for a one-time fee. Nobody can do that; vendors who claim they can have simply priced it into the quote already.

Myth 2: "A longer warranty means better protection"

Reality: Warranty length correlates weakly with the protection you actually receive. What matters is scope definition and response time. A twelve-month warranty with no stated response window, no reproducibility standard, and no environment scope is functionally identical to three months, because every single ticket gets re-argued from scratch. Conversely, a 90-day warranty that says "judged against the signed acceptance test cases, response within 48 hours, reproducible defects fixed free" gives the client far more certainty.

Myth 3: "Once the system is built, we stop spending"

Reality: Your runtime has an official lifecycle and it will not wait for you. Each PHP branch gets two years of active support, Node.js LTS lines run about 30 months, and Google Play raises its mandatory target API level every year. This is not vendors inventing work; skipping it means your system stops functioning or gets delisted. Not budgeting for maintenance does not remove the cost, it defers it into one painful bill in year three.

Myth 4: "Monthly maintenance fees are how vendors trap clients"

Reality: The actual trap is not a monthly fee. It is no source code, no documentation, no deployment access. A retainer that includes "terminable at any time, with full source code and environment documentation handed over on termination" leaves you free to walk. The test is simple: ask the vendor, "If I want to switch providers in three months, what do I get?" The ones who cannot produce a list are the dangerous ones.

Core framework: three rings of post-launch responsibility

Drop every post-launch ticket into one of three rings and roughly nine out of ten disputes dissolve on the spot.

Ring	Definition	Who pays	Typical duration
Ring 1: Warranty	Delivered work does not match the signed acceptance spec	Vendor absorbs	30–90 days after acceptance
Ring 2: Maintenance	External change breaks or endangers existing function (dependency upgrades, platform policy, security patches, monitoring and backups)	Monthly retainer	Ongoing
Ring 3: Evolution	Requirements changed, new features, new workflows	Per change order or hour pool	As needed

Classify with three questions, in order, and there is nothing to argue about:

Q1: Does the behaviour contradict the acceptance spec or test cases that passed at sign-off? Yes, go to Q2. No, it is Ring 3.
Q2: Is the cause inside the code and configuration we delivered (not a third-party change, not client-side data or operator error, not an environment change)? Yes, go to Q3. No, it is Ring 2.
Q3: Was it reported inside the warranty window with reproducible steps? Yes, Ring 1, fixed free. No, Ring 2 or Ring 3.

The value here is not assigning blame. It is replacing an argument about goodwill with a classification against criteria. Both sides can run it themselves and reach the same answer.

Three contrasting scenarios

Small marketing site (NT$80,000–250,000, company revenue under NT$30M): 30 days of warranty is enough, then a Tier 1 plan at NT$4,000–8,000/month. Risk here concentrates in three places: certificate expiry, CMS security updates, domain renewal. No hour pool needed.
Operational internal system (NT$600,000–1.5M, 30–150 staff): Downtime costs orders directly, so run a 60–90 day warranty with an 8-hour response commitment, then Tier 2 at NT$12,000–25,000/month including a 4–8 hour pool. The classic mistake at this size is saving the retainer and paying triple in emergency rates in month 14.
Customer-facing platform or mobile app (NT$1.5M+): Payments, personal data, and store review are involved, so Tier 3 at NT$35,000–80,000/month is the realistic floor. The driver is not complexity but the compliance clock: app store policies and payment rules move every year, and no routine maintenance means standing exposure to delisting.

The hidden post-launch cost list

Classification arguments themselves: 1–1.5 hours per ticket in back-and-forth. Those 31 opening tickets burned roughly 40 hours producing nothing of value for either side.
Third-party breaking changes: Payment, logistics, and social login SDKs average 1–3 breaking changes a year, 4–16 hours each.
Mandatory platform updates: One target API bump a year for mobile apps, 8–24 hours; skip it and you cannot ship updates at all.
Runtime EOL upgrades: A major language version jump typically costs 20–60 hours, NT$40,000–120,000, and cannot be split into small increments.
Data growth: After two to three years queries slow down; index and pagination rework runs 15–40 hours.
Expired certificates and domains: One missed renewal costs 0.5–2 working days of incident handling plus reputational damage.
Handover gaps: When the original vendor stops supporting, a new team needs 30–80 hours just to learn the codebase — money that buys zero new features.
The in-house alternative: An engineer capable of handling all of this starts around NT$55,000/month; with statutory insurance and pension contributions the loaded cost is roughly 1.18x, about NT$780,000 a year. For reference, Taiwan's statutory minimum wage rises to NT$29,500 per month from 2026, and technical roles sit far above that floor.

Totalled up, an NT$850,000 system carries a real second-year maintenance cost of NT$96,000–240,000, roughly 11%–28% of the build price. Leaving it out of the budget does not make it disappear. It only makes it late.

Four maintenance tiers and a pricing formula

Tier 0, self-managed (NT$0): Source code, deployment docs, and an account inventory are handed over; you take it from there. Suitable when you have internal IT.
Tier 1, basic protection (NT$4,000–8,000/month): Monitoring, backup restore verification, certificates and domains, security updates, 5-working-day response.
Tier 2, standard maintenance (NT$12,000–25,000/month): Tier 1 plus quarterly dependency upgrades and a 4–8 hour change pool, 1-working-day response.
Tier 3, deep partnership (NT$35,000–80,000/month): Tier 2 plus a named contact, 16–30 hour pool, 4-hour response, quarterly roadmap review.

To sanity-check any quote, use this: monthly fee ≈ (annual required maintenance hours ÷ 12 × hourly rate) + standby premium + hour pool. Estimate annual required hours as: core dependencies × 2 hours + integrated third-party services × 3 hours + mandatory platform updates × 8 hours + a fixed 12 hours for monitoring and backups. If your number and the quote differ by more than 2x, ask the vendor to itemise.

Contract clauses you can paste directly

Warranty definition: "Warranty means a discrepancy between the delivered work and the acceptance test cases signed by both parties, which is reproducible by the Vendor. The warranty period is 90 calendar days from the date of acceptance sign-off."
Warranty exclusions: "The following are excluded from warranty and shall be handled under the maintenance agreement or a change order: (a) changes to third-party services, APIs, or platform policies; (b) modifications to code, configuration, or data made by the Client or its appointed third parties; (c) faults in the Client's network, hardware, or account permissions; (d) requirements added or changed after acceptance."
Response and remediation targets: "Severity P1 (system unusable): response within 4 hours, remediation plan within 1 working day. P2 (major function impaired): response within 1 working day. P3 (minor defect): response within 3 working days. All targets are measured during working days, 09:00–18:00."
Dispute handling: "Where classification of an item is disputed, both parties shall apply the three-question test in the contract annex item by item. Items without consensus shall be provisionally logged as change orders and shall not block progress on other items."
Termination and handover: "Either party may terminate the maintenance agreement on 30 days written notice. On termination the Vendor shall deliver complete source code, database schema, deployment documentation, an environment variable inventory, and transfer of third-party accounts at no additional charge."
Hour pool rollover: "Unused hours included in the monthly fee may roll over to the following month, capped at two months of accumulated entitlement, and are not convertible to cash on termination."

A 12-point vendor scorecard

Ask every item before signing. Score 0–3 each, 36 maximum. Below 24, fix the contract before negotiating price.

☐ 1. Does the contract explicitly define warranty scope and exclusions?
☐ 2. Are there tiered response targets (P1/P2/P3)?
☐ 3. Is there an objective dispute classification process rather than case-by-case negotiation?
☐ 4. Does the retainer itemise what is included and the size of the hour pool?
☐ 5. Are monthly or quarterly maintenance reports provided?
☐ 6. Does the vendor proactively track runtime and dependency EOL dates?
☐ 7. Are backups periodically restore-tested, not merely taken?
☐ 8. Is there monitoring and alerting, with alerts reaching the client side too?
☐ 9. Are termination terms clear, including source code and account handover?
☐ 10. Are deployment docs and environment variable inventories delivered so a third party could take over?
☐ 11. Are emergency, after-hours, and holiday rates agreed in advance rather than quoted after the fact?
☐ 12. Is the vendor willing to start with a one-month trial instead of a mandatory annual lock-in?

How ScriptWalker handles this, and when we are the wrong fit

Our standing practice: every project quote ships with the warranty clause and the four maintenance tiers attached, so clients know their second-year cost at signing rather than discovering it after launch. Warranty is always 90 days with the three-question test annexed, and maintenance agreements are always terminable on 30 days notice.

On engagement models, most clients fit a retainer at Tier 1 or Tier 2. Companies with internal IT usually fit advisory, where we only run quarterly health checks and EOL early warnings. Complex systems on a compliance clock go to full outsourcing.

When we are the wrong fit:

You expect "pay once, fixed forever, free." We will not promise that, and anyone who does is hiding the risk somewhere else.
You want a retainer under NT$3,000/month with a 4-hour response commitment. The standby cost alone exceeds that; accepting it guarantees poor service.
The system was built by someone else, with no source code and no documentation, and you want a fixed maintenance price up front. We only take these after a takeover assessment (8–16 hours).
You plan to use the maintenance channel as free administrative help for anything and everything. The hour pool will drain fast and neither side will be happy.

Launch playbook

Two weeks before launch: Freeze and sign the acceptance test cases. This document is the sole warranty criterion later; without it, no warranty clause is enforceable however well written. Run one backup restore drill.
Days 0–30 after launch: Peak period. A 30-minute weekly sync; classify every ticket before scheduling it. Roughly 70% of issues this month are genuine warranty items, and that is normal.
Days 31–90: Move to biweekly. Mixed Ring 2 and Ring 3 tickets start appearing; walk the client through the three-ring test once in full so they can classify their own tickets. Do this step and the following year is almost argument-free.
Day 90: Issue a warranty closing statement 14 days before expiry, listing fixed items, pending items, and items classified as maintenance or new requirements. Present the maintenance tier recommendation and second-year budget alongside it.
Month 4 onward: Maintenance rhythm. A monthly report covering what was done, hours consumed, and next month's risks; a quarterly review of EOL dates and dependency upgrades.

Decision checklist

☐ Is "warranty" explicitly defined in your contract?
☐ Do you have signed acceptance test cases?
☐ Are warranty exclusions written down?
☐ Are response targets tiered by severity?
☐ Is there an objective classification process for disputes?
☐ Do you know when your language and framework hit EOL?
☐ Have you budgeted year-two maintenance?
☐ Have your backups ever been restore-tested?
☐ Do monitoring alerts reach your side?
☐ Do you hold complete source code and deployment docs?
☐ Are third-party service accounts registered under your name?
☐ Can the maintenance agreement be terminated on 30 days notice?
☐ Are emergency rates agreed in advance?
☐ Have you estimated the cost of switching vendors?

Fewer than 9 checked and your next incident will start with two weeks of arguing about responsibility before anyone starts fixing.

Frequently asked questions

How long should a warranty period actually be?

Ninety days is the sensible default for small and mid-sized custom projects in Taiwan. What matters is density, not length: issues cluster heavily in the first 30 days, and 90 days covers one full month-end close plus a seasonal traffic cycle. Demanding a full year rarely helps, because roughly 80% of what surfaces after month four is caused by external change and falls outside any warranty definition anyway. Sharpen the response targets and the classification process instead.

A third-party API changed and broke our system. Whose problem is that?

Ring 2, maintenance, not warranty. The vendor built against the API spec that existed and passed acceptance, so there is no defect. But the client should not carry that risk alone either, which is exactly why a maintenance retainer exists. If you chose the self-managed tier, it gets handled as a time-and-materials change order. Write this into the warranty exclusions clause explicitly.

Can we skip the retainer and just call the vendor when something breaks?

Yes, if you accept two things. Your work queues behind retainer clients, typically 3–10 working days before anything gets scheduled, and emergency rates usually run 1.5–2x the standard hourly rate. If a day of downtime costs you less than NT$5,000, that is a rational choice. Above that number, a Tier 1 retainer already pays for itself.

How do I tell whether a maintenance quote is padded?

Ask for an itemised breakdown and run the formula yourself: annual required maintenance hours ÷ 12 × hourly rate, plus standby premium and hour pool. Then check two things — whether the fee includes a concrete hour pool (if not, it is pure standby and should be much cheaper), and whether monthly maintenance reports are provided. Without reports you cannot verify what your money bought.

We are already in a fight with our vendor. How do we stop the bleeding?

Three steps. First, list every disputed ticket in one table, recording only, no debating. Second, run the three-ring test line by line and immediately schedule the Ring 1 items both sides agree on, so progress restarts. Third, bundle Ring 2 and Ring 3 into a single maintenance-plus-change proposal and negotiate price and schedule once, not ticket by ticket. In practice this compresses a two-to-three week deadlock into about five working days.

Want your year-two maintenance cost calculated first?

ScriptWalker offers a post-launch cost review: we apply the three-ring framework and the estimation formula above to inventory your system's EOL timelines, third-party dependencies, and real maintenance hours, then deliver a second-year budget with contract remediation recommendations (4–8 hours, from NT$8,000, free for existing project clients). We also run takeover assessments for systems built by other teams.