The Hidden Risk in Your IT Contracts

Last week, I finished Justin Welsh’s courses - great stuff, highly recommend them. While reviewing my notes, one idea kept jumping out: specificity wins. Every. Single. Time.

This isn’t just about marketing or sales. It’s about the one document most IT agencies and software teams treat as an afterthought: your contracts.

Let’s say you’re working on a project for a client. The contract has a line like, “Vendor will use best efforts to resolve issues post-launch.” 

Sounds harmless, right? Fast-forward three months, and you’re stuck in a nightmare where the client expects you to rebuild their entire API gateway for free because “best efforts” weren’t defined.

This happens all the time in IT. A vague clause here, a broad promise there, and suddenly, a project that should’ve taken 100 hours balloons into 500.

Your team burns out, your margins vanish, and the client still isn’t happy. Let’s fix that.

Why “Best Efforts” Is a Trap (And How to Avoid It)

“Best efforts” sounds fair on paper. You’re promising to try hard; the client feels reassured.

But the problem is: courts have ruled that “best efforts” means doing everything possible to meet the obligation - even if it bankrupts you.

Here’s how this plays out in real life for IT teams:

Scenario 1:

You’re a software agency. A client’s e-commerce site crashes during Black Friday. Your contract says you’ll use “best efforts” to fix it.

Now they’re demanding you work nights and weekends, hire third-party experts at your cost, and compensate them for lost sales.

Scenario 2:

You’re a cloud services provider. A client’s data migration hits a snag, and your contract vaguely promises “timely resolution.”

They interpret this as a 24/7 all-hands-on-deck emergency. You interpret it as “We’ll fix it during business hours.” Now you’re in a standoff.

The fix? Ditch ambiguity. Here’s how.

3 Actionable Fixes for IT Contracts

1. Replace “Best Efforts” With Metrics That Matter

Vague promises leave room for interpretation. Specific metrics don’t.

For software development:

• Instead of: “We’ll use best efforts to fix bugs.”

• Use: “Critical bugs (e.g., system crashes, security flaws) resolved within 48 hours. Minor bugs (e.g., UI glitches) addressed within 14 business days.”

For IT support:

• Instead of: “Provide timely server maintenance.”

• Use: “Guarantee 99.9% uptime. Scheduled maintenance occurs every second Tuesday, with 72-hour advance notice.”

Side tip: Borrow from SLAs (Service Level Agreements). Define “critical,” “major,” and “minor” issues with exact response times.

2. Add a Kill Switch for Open-Ended Work

Unlimited revisions, endless support hours, or scope creep can sink your profitability. Protect yourself with:

• Time limits: “Includes up to 10 hours of post-launch support per month. Additional hours billed at $150/hour.”

• Budget caps: “Efforts cease if resolution requires more than $5,000 in third-party costs.”

• Termination triggers: “Either party may exit this agreement if three consecutive deadlines are missed.”

3. Define Failure (So Everyone Knows When to Walk Away)

Not every IT problem has a fix. Maybe the client’s legacy systems are too outdated, or their budget can’t cover the necessary infrastructure. You can protect both sides with clear exit terms:

• “If unresolved after two dedicated sprints (4 weeks total), Client may terminate and receive a prorated refund.”

• “If third-party vendor delays exceed 30 days, Client covers additional costs or may cancel the project.”

And this works for a simple reason - Clients appreciate honesty. It shows you’re not just chasing billable hours.

Your IT Contract Checklist

Before signing your next agreement, ask:

1. Does “best efforts” appear anywhere? Replace it with time-bound, measurable terms.

2. Are there caps on revisions, support, or costs? If not, add them.

3. Is there a clear exit plan? Define what happens if the project stalls or fails.

4. Have you borrowed from SLAs? Use industry-standard metrics for uptime, response times, and severity levels.

Final Thought: Specificity = Profitability

Vague contracts don’t just risk legal trouble - they erode trust and trash your margins.

When you’re clear about what’s included, what’s extra, and what’s impossible, you protect your team, your client, and your bottom line.

Remember: In IT, the difference between a profitable project and a money pit isn’t your skills - it’s your contract.