Helper CTO Series 07 | What a Maintenance Contract Should Actually Say: Response Time, Update Frequency, Exit Terms, Document Ownership

"The contract says 'provides system maintenance services' — doesn't that cover everything?" You find out it doesn't only after something goes wrong: the day the site goes down, you call and they say "we'll take a look tomorrow." You ask about backups, and they say "the contract doesn't say we have to back anything up." You want to switch vendors, and they say "the code is our intellectual property." Every one of those answers is technically consistent with the contract — because the contract never actually spelled anything out. You weren't deceived; nobody was willing to hash out the details on the day you signed. Here are the four places you need to read word for word before you sign.

The vaguer the contract, the less accountable anyone is when something breaks

A vague contract is easy on both sides — no need to hash out details when signing, and the mood stays pleasant. The cost shows up later:

• Every single incident turns into a fresh negotiation over whether it's their responsibility.
• You're negotiating while you're panicking; they're not. You have no leverage; they do.
• If you can't agree, you're stuck — because the cost of switching vendors is also written into that same vague contract.

You don't need to code to manage outsourcing well covers how managing a vendor relies not on technical knowledge but on spelling out the rules clearly, and the contract is that set of rules. Three ways maintenance fees are calculated mentioned four places to check in a contract — this article expands each one.

Four places to check, starting with a comparison table

Pull out the contract you currently have and compare it against the middle column. Any match is a place worth renegotiating.

Response time and update frequency: does anyone actually move on the day something breaks

Response time is a guarantee that someone is actually working on it. What to check:

• How quickly work starts when the server or a service goes down, and how quickly you get an assessment back after reporting a bug.
• The definition of "response" needs to be spelled out: "we've received it" doesn't count; "here's what the problem is and how we plan to handle it" does.
• A contract that states a time limit but never defines what counts as meeting it is functionally the same as one that states nothing.

Update frequency governs a risk you can't see. New vulnerabilities keep being found in underlying packages, and attack tools show up fast once a vulnerability goes public — and they scan the entire internet automatically. What to check:

• Whether a minimum frequency is stated, instead of "as needed" or "coordinated with the vendor."
• Whether emergency patching kicks in separately when a critical vulnerability goes public.
• Whether updates are logged, so you can see exactly what was updated in a given month.

Exit terms and document ownership: what you actually get to keep when you leave

Exit terms determine the cost of switching vendors. Maintenance is a long-term relationship, and long-term means you might want to switch someday, sometimes for a reason as simple as a change in budget. What to check:

• Whether you can stop, how much advance notice is required, and whether there's a penalty for remaining months.
• Whether ownership of the code, data, server account, and domain account is clearly stated after termination.
• If a vendor insists on a lock-in, ask why. A reasonable answer is "first-time cleanup costs a lot" — in that case, quote the cleanup separately instead of folding it into a lock-in contract.

Document ownership determines whether the next person has to start an excavation from scratch — and you're the one paying for that dig. The contract should list at minimum what gets delivered when the engagement ends:

• Where the system runs, how it's deployed, and where the data is stored.
• What accounts and external services exist, and who owns each one.
• How common issues are handled, plus a change log covering the engagement.

What Nerdtechnic's contract actually says

• A response within 1 business day when the server or a service goes down; an assessment within 2 business days when you report a bug.
• Security updates at least once a quarter, with emergency updates added on top when needed.
• Billed monthly, and you can stop anytime; basic maintenance starts at NT$6,000/month, with first-time cleanup to get to a proper launch state quoted separately based on condition, never folded into a lock-in contract.
• When the engagement ends, the documentation and records are yours — switching to someone else doesn't turn into a black box.

This isn't asking you to sign with us — it's giving you a benchmark. Take these four items to any vendor and ask. Only the ones who can actually answer are worth negotiating with.

Once the contract is spelled out clearly, all that's left is whether anyone actually follows it. Nerdtechnic takes over and maintains your system as Helper CTO — like an in-house tech lead, just not on your payroll — and these commitments are written into the contract itself. The first step is a 60-minute system health check: we only need to see the code, no credentials to your production environment required, and within 3–5 business days you'll get a one-page report you can actually understand, then decide whether to work with us. If the contract you're holding right now is exactly the "provides system maintenance services" type, you can start here: Helper CTO: System Maintenance Plan.