Before you sign another vendor contract, ask these questions first.


Issue #17

Hey there, fellow accidental techie ๐Ÿ‘‹

Have you been surprised by a renewal?

Maybe it was the invoice that came in higher than last year, with a line about "standard price adjustments" and no explanation of what standard meant. Maybe it was the afternoon you tried to pull your donor records out of a platform you'd decided to leave, and learned that the export costs extra and the window to do it closes 30 days after you cancel. Maybe it was a consultant who quoted you a clean project fee in the spring, and by midsummer you were three invoices deep into work nobody had written down.

Here's what I want you to notice about all three of those. None of them requires a dishonest vendor. Every one of them is a contract doing exactly what it says, to a person who didn't fully read what it said, because reading vendor contracts was never the job you were hired to do. It landed on you the same way everything technical lands on you. Someone had to sign, you were the one who knew where the account lived, and now the renewal is your problem.

So let's make it a smaller problem. Not by turning you into a procurement officer or a contracts lawyer, because you have neither the time nor the budget for that, and pretending otherwise is how these newsletters lose you. The realistic goal is narrower and more useful. There's a short list of questions that matter before your name goes on anything, and that list changes depending on who's on the other side of the table. Get the list right and most of the ugly surprises stop happening.

I've signed these contracts across four organizations, from a shop running on $400K to one moving $40M, and I've been burned by every mistake I'm about to describe. This is the version of the advice I wish someone had handed me before my first vendor call, instead of the version I assembled the hard way.

What's in this issue:

โœ… Why "we specialize in nonprofits" quietly lowers your defenses, and what to do about it

โœ… The five contract terms that carry most of the risk, with the actual language to ask for

โœ… The pitfalls that repeat across organizations and how each one gets you

โœ… Different question sets for an MSP, a software vendor, and a consultant

โœ… How to negotiate real improvements without a lawyer or a procurement department

โœ… What I'm reading


The pitch that lowers your guard

Think about how you feel when a salesperson opens with pure sales energy. Guard up, wallet closed, you're already looking for the catch. Now think about how you feel when a vendor leans across the table and says, "We work with organizations just like yours. We get the constraints you're under." Something in you relaxes. Finally, someone who understands that you're not a Fortune 500 company with an IT department and a legal team.

That relaxation is the entire risk, and it's worth sitting with why. Nonprofit staff are mission-driven people, and mission-driven people extend trust based on shared values. It's a good instinct in most of your work. It's a liability in a contract negotiation, because a vendor's understanding of your mission has nothing to do with how their cancellation clause is written. The two live in completely different parts of the relationship. One is a feeling in a sales meeting. The other is a legal document that outlives the salesperson, survives their departure from the company, and gets enforced by a billing system that has never heard of your mission.

I've watched genuinely good vendors, people who cared about the work and delivered real value, hand over contracts that quietly protected them at my expense. Not out of malice. Out of habit, because that's how their standard paper is written, and nobody on my side had ever asked them to change it. That's the part most accidental techies miss. The contract isn't adversarial because the vendor is a villain. It's just written from their side of the table, and if nobody negotiates from your side, their side wins by default.

And here's the structural reality that makes all of this harder for you specifically. In a company of any size, a contract passes through several sets of eyes before anyone signs. Procurement reads the pricing. Legal reads the liability. Someone in IT reads the security terms. You have none of that. You are procurement, legal, and IT, usually while also running a program and answering an email from your ED that starts with "quick question." Your board might approve the dollar amount, but a board member is not going to catch a 90-day auto-renewal notice sitting on page eleven of an exhibit. The safeguard that exists in every other sector, more than one informed person reading the document, does not exist for you unless you build a version of it yourself.

The good news is that you don't need to replicate a whole procurement department. You need to be the informed reader for a handful of clauses that do most of the damage. That's a real skill, but it's a small and learnable one, and the rest of this issue is that skill.


The five terms that carry the risk, and the language to ask for

A vendor contract can run 30 pages. Five clauses do almost all of the protecting, and if you only ever learn to read five things, learn these.

Data ownership and export. Start here, because this is the one that turns a routine decision into a hostage situation. The question is not just "do we own our data," which most vendors will happily confirm, but "can we get our data out, in a format we can actually use, without paying a ransom or racing a clock." Those are different questions and the second one is where people get trapped. I have seen a contract that granted full data ownership on paper and still made leaving nearly impossible, because the export came out as a proprietary file that needed the vendor's own software to open, with a 30-day window after cancellation before everything was deleted. You owned your data the way you own a car with the keys locked inside.

What to ask for in writing: the right to export your complete data in a standard, non-proprietary format such as CSV or a documented file type, at any time during the contract and for at least 60 days after it ends, at no additional charge. If a vendor won't put that in writing, you've learned something important before you signed instead of after.

โ€‹
โ€‹Auto-renewal and cancellation notice. Many contracts renew themselves automatically unless you give written notice inside a specific window, and that window is often much earlier than feels intuitive. Ninety days is common. A hundred and twenty is not rare. Miss it by a day and you're committed to another full term, sometimes multiple years. The clause is usually not hidden, exactly, but it's written to be forgotten, and it works.

The fix costs nothing and takes two minutes. The day you sign, put a calendar reminder two weeks before the notice window opens, with the exact cancellation instructions pasted into the reminder. Not the renewal date. The date you'd have to act by, minus a buffer. That single habit has saved me more money than any negotiation.

โ€‹
โ€‹Price-increase caps. "Standard annual adjustment" is not a number, and any phrase that isn't a number is a blank check you're signing. I've seen "standard" mean three percent one year and a lot more the next, always with a reasonable-sounding explanation attached. Ask what the increase can be, and get an actual ceiling written down: a fixed percentage, or a specific index like CPI, or a flat "no more than X percent in any renewal term." Vendors who intend to treat you fairly rarely object to writing down the number they say they already follow. The ones who resist are telling you something.

โ€‹
โ€‹Termination for convenience. This is the escape hatch, and most standard contracts don't include one unless you ask. It answers a simple question: can you leave before the term is up if the relationship stops working, and what does it cost you. Some contracts let you exit with 30 or 60 days' notice and a prorated refund. Others hold you to every remaining month no matter how badly things are going. The difference between those two is the difference between a manageable mistake and an expensive one, and you decide which you're signing up for before, not after.

Scope and change-order language. This is the one that gets accidental techies most often, and it deserves the most attention, so we're giving it its own section below.


Scope creep, and the one sentence that stops it

Here's the pattern, and see if it sounds familiar. You hire a consultant or a small firm for a defined project. Migrate the CRM, build the reporting dashboard, clean up the email system. The quote is clean, the timeline is reasonable, everyone's optimistic. Then a few weeks in, something comes up that wasn't in the original description. "While we're in here, we should probably also fix the duplicate records." "This integration is more complicated than it looked, it'll be some extra hours."

Each request sounds reasonable on its own, because each one usually is. And there's no natural moment to stop and ask what it costs, because you're already working together and it feels rude to slow things down over money.

That's scope creep, and it's worse with solo consultants and small firms than with big vendors, which is the opposite of what most people expect. A large vendor has a project manager whose literal job is to log every change and attach a price to it. That feels bureaucratic, but the bureaucracy is protecting you as much as them. A solo consultant has no such buffer. It's just you and them, often on a first-name basis, sometimes someone you genuinely like, and there is enormous social pressure not to be the person who says "wait, is that extra?" So the hours accumulate, the invoices grow, and by the end you've paid 40 percent over the quote and you're not even sure where it went.

The principle to hold onto is this: if you're already thinking about it, it belongs in the contract. Not because you distrust the person. Because a written scope protects the relationship from the awkward conversation, which means you can keep liking each other while still being clear about money.

And there's a specific mechanism that works better than trying to define every possible task in advance, which is impossible anyway.

Negotiate a bucket of additional hours, up front, at an agreed rate. Something like: the project fee covers the defined scope, plus a pre-approved block of, say, 20 additional hours at the agreed hourly rate, to be drawn down for work outside the original scope, with a simple email confirmation before each draw. Now when something new comes up, nobody's renegotiating from zero and nobody's absorbing a surprise.

You're pulling from a pool you already priced and agreed to, the consultant gets paid fairly for real extra work, and the awkward conversation becomes a two-line email instead of a tense phone call. Everyone stays comfortable, and comfortable relationships are the ones that deliver good work.

Join The Accidental Techie Community in Linkedin


The pitfalls that repeat

โ€‹
After enough of these, you start to see the same handful of traps across completely different vendors and sectors. Naming them is half the defense.

โ€‹
โ€‹The auto-renewal nobody's tracking is the most common, and we've covered the fix, but it's worth saying that it almost never fails loudly. It fails as a quiet invoice for a service you'd already mentally moved on from.

โ€‹
โ€‹The verbal promise that never made it into writing is the one that stings, because it usually involves a salesperson you trusted. They told you the integration was included. They told you the discount was permanent. They told you support was 24/7. None of it is in the document, which means none of it is real the moment there's a disagreement, and the salesperson who promised it may not even work there anymore. If it matters, it goes in the contract, or at the very least in an email you keep.

โ€‹
โ€‹Bundled implementation and support is a subtler one. Many vendors package the one-time setup and the ongoing service into a single multi-year term, so even if the implementation goes perfectly and the ongoing support turns out to be mediocre, you can't separate them. You're locked into the weak part because it was stapled to the strong part. Ask whether you can contract for implementation and ongoing support separately, or at least whether the ongoing piece has its own exit.

โ€‹
And the disappearing nonprofit discount is the one that's specifically aimed at you. The generous first-year rate that made the decision easy was written as an introductory price, not a permanent one, and at renewal it quietly reverts to standard. This isn't always predatory, sometimes it's just how the pricing works, but you need to know which kind you're signing. Ask directly: does the nonprofit rate apply for the life of the contract, including renewals, or only for the initial term? Then get the answer in writing, because you already know what a verbal answer is worth.


The questions to ask, and why they're different for each vendor

A single generic checklist fails you because these three kinds of vendors fail you in three different ways. An MSP fails you on responsiveness and lock-in. A software vendor fails you on your data and your renewal price. A consultant fails you on scope and ownership. Ask each one the questions that match how they actually go wrong.

โ€‹
โ€‹If you're hiring a managed service provider (MSP):

  • What's the guaranteed response time for a critical issue, written into an SLA, and what counts as "critical" in their definition versus yours? Ask for the number, because "as soon as possible" is not a commitment, it's a mood.
  • What's the escalation path when the first person you reach can't solve it, and how do you trigger it?
  • What is the total contract length, and what specifically happens to your data, your accounts, and your administrative access on the day the relationship ends?
  • Who owns responsibility when there's a security incident, and does "responsibility" mean they fix it, they're liable for it, or just that they'll help you clean up? Get those boundaries clear now, because the middle of a breach is the worst possible time to discover you and your MSP had different assumptions.

If you're signing a software or SaaS vendor:

  • What format does our data export in, does it cost anything, and how long is the window after cancellation?
  • Is your price-increase language an actual number or a phrase, and if it's a phrase, will you replace it with a number?
  • What happens if we need to cancel mid-contract rather than at renewal, and what does that cost?
  • Does the nonprofit discount apply to renewals or just the first term?
  • And one people forget: what's your uptime commitment, and what do we get if you don't meet it? A vendor confident in their service will put a number on it.

If you're hiring a consultant or small firm:

  • How is the scope defined in writing, and what's the exact process when something falls outside it?
  • What happens if the timeline slips on their end rather than because of a delay on yours?
  • Who owns the deliverables, the code, the configurations, the documentation, once the project is done and paid for? You'd be surprised how often the answer to that last one is "we do," which can leave you unable to hand your own systems to the next person without paying the first one again.
  • And is payment tied to milestones and completed work, or just to time passing? Milestone-based payment keeps everyone honest and gives you a way to pause if the work stalls.

How to negotiate without a lawyerโ€‹
โ€‹

The word "negotiate" makes a lot of accidental techies freeze, because it sounds like a skill you were supposed to learn somewhere and didn't. Let me lower the stakes. Negotiating a vendor contract mostly means asking for a few specific things and being willing to hear no. That's it. Most vendors expect it, most have room to move, and the worst realistic outcome is that they say no and you're exactly where you started. There is very little downside to asking, and people who never ask leave real money and real protection on the table every year.

โ€‹
Three moves give you most of the benefit.

โ€‹
โ€‹Ask for a shorter initial term, even if the per-year price is a little higher. A vendor will often trade a lower annual rate for a longer commitment, and that trade is usually bad for you in year one with someone new. You don't yet know if this relationship works. Paying a small premium to keep a one-year term instead of a three-year one is buying yourself an exit, and an exit is worth paying for when you're not yet sure. Once the vendor has proven themselves, you can lock in the longer term and the better rate with real information instead of hope.

โ€‹
โ€‹Get the price cap written as a number before you sign, not after. This is the single highest-value sentence you can add to most contracts, and the moment to add it is while they still want your signature. "We'll be reasonable at renewal" costs them nothing to say and protects you not at all. "Increases will not exceed 5 percent in any renewal term" is a number you can hold them to. Ask for it plainly: "Before I sign, I need the annual increase capped at a specific percentage in the document." Then stop talking and let them answer.

โ€‹
โ€‹Confirm every sales promise in writing, even when you can't get it into the contract itself. Sometimes a rep genuinely can't change the standard contract, and that's real. What they can almost always do is reply to an email. After the call, send a short note: "Confirming what we discussed, the integration is included at no additional cost and the nonprofit rate holds through renewals." Ask them to confirm. An email thread isn't as strong as a contract clause, but it's dramatically stronger than your memory of a phone call, it costs nothing, and it's evidence if the person who promised it is gone by the time it matters.

โ€‹
Here's what success actually looks like, and it's smaller than you'd think. It's walking into your next vendor call with a short list of questions already written down, instead of leaving the call with a good feeling and no protection. It's a calendar reminder set the day you sign, so no renewal ever surprises you again. It's one email, sent after the call, that turns a promise into a record. None of that requires a law degree or a procurement team. It requires knowing which few things matter and refusing to sign until they're handled, and that's a habit you can start on your very next contract.

Until next time,

Hugo

Join the Waitlist

A 6-week cohort program for nonprofit professionals ready to stop firefighting and start shaping technology strategy.

Join the waitlist for early access and beta pricing.

BEFORE YOU GO

None of this makes you a contracts lawyer, and it was never supposed to. It makes you the informed reader that every other sector has by default and yours doesn't, the person who knows which five clauses matter and won't sign until they're right. That's the whole difference between a vendor relationship that holds up when things get hard and one that surprises you the day the invoice arrives.

P.S. If someone else at your organization signs vendor contracts, a program director, a finance lead, whoever handles renewals, forward this to them before the next one comes up for signature, not after it's already signed.

600 1st Ave, Ste 330 PMB 92768, Seattle, WA 98104-2246
โ€‹Unsubscribe ยท Preferencesโ€‹