Nonprofit Website Vendor Red Flags to Watch For
Want an engaging website?
The most expensive website mistake a nonprofit makes is not choosing the wrong design. It is signing the wrong contract. The pitch is always polished. The red flags are in the fine print and in how the vendor answers a handful of specific questions before you sign. A vendor that owns your content, bills for every small change, auto-renews without notice, or cannot tell you how you would leave is a vendor that has structured the relationship in their favor, not yours.
This post is a pre-signature checklist. We have spent two decades rebuilding sites for organizations that got trapped: platforms sold out from under them, designers who vanished, content they could not export, and contracts that renewed automatically at a higher rate. Every one of those situations was predictable from the vendor's answers before the contract was signed. Below are the red flags to watch for, the questions that surface them, and what a trustworthy answer sounds like.
|
7 red flags to check in the contract and the vendor before you sign |
3-5 years the typical length a bad website contract locks an organization in |
1 question that reveals more than the rest: "How would we leave, and what do we take with us?" |
Quick answer: The seven biggest website vendor red flags to check before you sign are: you cannot export your content and data (you do not truly own it), the vendor bills per change for routine edits, the contract auto-renews without notice or has hidden renewal clauses, the platform is proprietary with no clear exit path, support is slow or depends on a single person, the vendor could be acquired or shut down without protecting your site, and there is no named team accountable for the work. The single most revealing question to ask any vendor is: "If we decided to leave in two years, what is the exact process, and what content and data do we take with us?" A vendor who answers clearly and in writing is safe. A vendor who gets vague is the risk.
Why the Contract, Not the Pitch, Is Where the Risk Lives
A website vendor relationship is a multi-year commitment, and the terms that determine whether it goes well are set before you sign, not after. By the time a red flag becomes a real problem, you are already locked in.
Organizations evaluate website vendors on the wrong things. They compare portfolios, designs, and price. Those matter, but they are the visible layer. The layer that actually determines your risk over the next three to five years is structural: who owns the content, how changes are billed, how the contract renews, how you would exit, and who is accountable when something breaks. These terms are rarely in the pitch. They are in the contract, and in the answers a vendor gives when you ask directly.
The reason this matters more for mission-driven organizations is leverage. A nonprofit, school, association, or hospital foundation with a small team has almost no leverage once the contract is signed and the site is built on the vendor's platform. If the vendor raises prices, slows support, or gets acquired, the organization's options are to accept it or to undertake an expensive migration. The time to have leverage is before you sign, when the vendor still has to earn your business. That is the window this post is about.
"Almost every trapped organization I have audited signed a contract that looked fine on the surface. The problem was never the thing they negotiated. It was the thing they did not think to ask about: what happens if we want to leave, who owns the content, what a 'change' costs. Those unasked questions are where the trap is built."
- Brent Lafreniere, Digital Director
Reviewed by Our Team
This post draws on two decades of rebuilding sites left behind by failed vendor relationships, and on the platform architecture that determines whether an organization can leave with its content intact.
Brent Lafreniere, Digital Director (Audit & Migration Experience) - 19 years in digital across schools, nonprofits, associations, and healthcare. Has audited hundreds of sites left behind by vendor relationships that went wrong, and led the migrations to fix them. Provides the red flags and the contract patterns in this post.
Murad Bushnaq, CEO & Creative Director (CMS Architecture & Data Portability) - 25+ years in web design, 15+ across Morweb's four verticals. Has guided the design and strategy of 500+ websites. Provides the platform perspective on data portability and what "you own your content" should mean legally and technically.
Red Flag 1: You Cannot Export Your Content and Data
If a vendor cannot tell you exactly how you would export your content, images, member data, and donor records, you do not own your website. You are renting it, and the vendor holds the key.
Data portability is the ability to take your content and data out of a platform in a usable format. It is the single most important term in any website contract, and the one most organizations never ask about. A site full of pages, blog posts, images, event records, member profiles, and donor data represents years of work. If that data cannot be exported cleanly, leaving the vendor means rebuilding everything from scratch.
We have rebuilt sites for organizations that discovered, only when they tried to leave, that their content was locked in a proprietary format with no export path. The vendor was not obligated to hand anything over, and the contract did not require it. The organization had to recreate years of content manually. The lesson is not that those vendors were malicious. It is that the contract never established who owned the data, so the answer defaulted to the vendor.
The Question to Ask
"If we leave, what content and data can we export, in what format, and is that guaranteed in the contract?" A trustworthy vendor answers specifically: pages and posts in a standard format, images and documents as files, structured data (members, donors, events) as CSV or a database export. Vague answers ("we would work with you on that") are a red flag. Get it in writing.
"'You own your content' has to mean something technical, not just a nice sentence in a proposal. It means you can export your pages, your images, your member and donor data, in a standard format, whenever you want, without asking permission. If a vendor cannot show you the export button or name the format, you do not own your content. They do."
- Murad Bushnaq, CEO & Creative Director
Red Flag 2: The Vendor Bills You for Every Small Change
If updating a photo, changing a date, or editing a paragraph generates an invoice, the vendor has built a business model on your dependency. The website becomes something you are afraid to touch because every touch costs money.
Per-change billing is a contract structure where the vendor charges for routine content edits, often at an hourly rate or a per-task fee. It is common among vendors whose platforms require technical skill to edit, because it turns the organization's inability to self-serve into recurring revenue. The organization ends up rationing website updates to control cost, which means the site goes stale.
We regularly audit sites where the organization stopped updating because every change went through the vendor at $75 to $150 an hour. Events from last year are still on the homepage. Staff listings are out of date. Not because the team did not care, but because keeping the site current would have blown the budget. A website you cannot afford to update is a website slowly going out of date on a schedule set by your invoices.
The Question to Ask
"Can our own staff make routine content changes without calling you, and at no additional cost?" The answer you want is that the platform lets non-technical staff edit any page themselves, and that the vendor only bills for substantial new work, not for edits. If routine changes require the vendor, you are signing up for a recurring bill and a stale site. We cover the true cost of this dynamic in our post on the real cost of a "free" website platform.
Red Flag 3: The Contract Auto-Renews or Hides Its Renewal Terms
An auto-renewing contract with a narrow cancellation window is designed to keep you paying by default. If you miss the window, you are locked in for another full term at whatever rate the vendor sets.
Many website contracts renew automatically unless the organization cancels within a specific window, sometimes 30 or 60 days before the term ends. Miss that window and you are committed for another year or multi-year term. Some contracts also allow price increases at renewal that are not capped or disclosed up front. The combination, automatic renewal plus uncapped price increases, means the organization can be locked into a rising bill it never actively agreed to.
This is not hypothetical. Organizations come to us mid-contract, wanting to switch, only to discover they auto-renewed months earlier and owe another year. The renewal clause was in the contract. Nobody flagged it at signing, and the vendor had no reason to remind them.
The Question to Ask
"How does renewal work, what is the cancellation window, and can prices increase at renewal?" A fair vendor discloses the renewal terms plainly, gives reasonable notice before renewal, and caps or discloses any increase. Watch for: automatic renewal with a short cancellation window, uncapped price increases, and multi-year terms with no exit. Read the termination and renewal sections of the contract before anything else.
Red Flag 4: The Platform Locks You In With No Exit Path
A proprietary platform with no clear way to leave is a strategic risk. The moment the vendor knows you cannot leave easily, every future negotiation, on price, support, or features, tilts in their favor.
Vendor lock-in is the situation where the cost or difficulty of switching platforms is high enough that you stay even when you would rather leave. Some lock-in is normal, every platform has switching costs. The red flag is a vendor who increases lock-in deliberately: proprietary content formats, no data export, custom code only they can maintain, and hosting only they control. Boards sometimes default to open-source platforms like WordPress specifically because they fear this, though that path carries its own maintenance burden, which we cover in our WordPress post.
The goal is not zero switching cost. It is a known and reasonable exit path. You want to be able to answer, before you sign, the question of how you would leave if you needed to, and to have that answer be something other than "we would have to rebuild everything."
The Question to Ask
"What does leaving your platform actually involve, start to finish?" A trustworthy vendor can describe the exit process without getting defensive: export your content and data, hand over your domain, and provide any assets you own. A vendor who treats the question as adversarial, or cannot answer it, is telling you that leaving is meant to be hard.
Red Flag 5: Support Is Slow, Vague, or Depends on One Person
When your site goes down or breaks, support response time is the only thing that matters. A vendor whose support depends on a single freelancer or an unstaffed inbox is a single point of failure on a site that may accept donations, registrations, or patient contact.
Support is the term organizations most overestimate at signing and most regret later. The pitch promises responsiveness. The contract rarely defines it. There is a large difference between a vendor with a staffed support team and a defined response time, and a vendor who is one busy freelancer answering email when they can. The second arrangement works fine until the day the site breaks and that person is on vacation, has moved on, or has too many clients.
The most common version of this failure we see is the disappearing designer. A freelancer or small shop built the site, then became unresponsive, moved on, or stopped supporting the platform. The organization is left with a site nobody will maintain and no contractual recourse. The relationship was never structured to survive one person's availability.
The Question to Ask
"What is your guaranteed support response time, who provides support, and what happens if my main contact is unavailable?" You want a staffed team, a defined response time in the contract, and support that does not hinge on one individual. If the honest answer is that support is one person doing their best, treat the site as if it has no support guarantee, because it does not.
Red Flag 6: The Vendor Could Be Sold or Shut Down Without Protecting You
Platforms get acquired, discontinued, and shut down. If your contract does not protect your site and data when the vendor changes hands, an acquisition you had no say in can leave you scrambling.
This red flag is easy to miss because it is about the future, not the present. But it is real. We have worked with organizations whose website platform was sold to a new owner who changed the terms, raised the prices, or discontinued the product, all without meaningful notice. The organization had built its entire web presence on a platform that no longer existed in the form they signed up for, and the contract gave them no protection.
You cannot predict an acquisition, but you can protect against it. The protection is the same as Red Flag 1: if you can export your content and data at any time, in a standard format, an acquisition is an inconvenience rather than a crisis. Data portability is the insurance policy for every other risk in this list.
The Question to Ask
"If your company is acquired or discontinues this product, what protects our site, our data, and our pricing?" Look for contractual continuity terms and, above all, the ability to export and leave. A vendor's stability today is not a guarantee about tomorrow. Portability is.
Red Flag 7: No Named Team Is Accountable for the Work
If you cannot identify the actual people who will build and support your site, you cannot hold anyone accountable. "The team" is not a name. Accountability requires names.
Some vendors sell through a polished front while the actual work is subcontracted to whoever is available, or handled by a rotating cast with no continuity. The organization never builds a relationship with a specific, accountable person or team. When something goes wrong, there is no one who owns the outcome, only a support queue and a shrug.
This connects to a broader principle we apply to our own work and recommend for any vendor: the people doing the work should be nameable, reachable, and consistent. That is also why every post on this blog carries named authors with real bios. Accountability is a person, not a logo.
The Question to Ask
"Who specifically will build our site, who supports it after launch, and will those people stay consistent?" You want named roles and continuity. A vendor who cannot or will not name the team is asking you to trust a process with no one accountable inside it.
The Pre-Signature Vendor Evaluation Checklist
Before you sign any website contract, run it through this checklist. Every item maps to a red flag above. Get the answers in writing, in the contract, not in the sales conversation.
- Data ownership and export. Can we export all content, images, and structured data (members, donors, events) in a standard format, any time, guaranteed in the contract?
- Self-service editing. Can our non-technical staff make routine content changes ourselves, at no extra cost?
- Change billing. What exactly triggers an additional charge, and at what rate?
- Renewal and cancellation. How does renewal work, what is the cancellation window, and can prices increase at renewal? Is any increase capped?
- Exit process. What is the full, written process for leaving, and what do we take with us?
- Support terms. What is the guaranteed response time, who provides support, and is it in the contract?
- Continuity. What protects us if you are acquired or discontinue the product?
- Named accountability. Who specifically builds and supports our site, and will they stay consistent?
- Hosting, security, and backups. Who is responsible, and what is the uptime commitment?
- Total cost of ownership. What is the all-in annual cost over three and five years, including setup, hosting, support, and any per-change fees?
What a Trustworthy Vendor Relationship Looks Like
The absence of red flags is not enough. A good vendor relationship is defined by positive terms: you own your content, your staff can edit the site, support is staffed and defined, and leaving is possible even if you never do it.
The organizations that avoid the traps in this post share a pattern. They chose a vendor whose business model does not depend on their inability to leave. Their content is exportable. Their staff can update the site without an invoice. Their hosting, security, and backups are the vendor's responsibility with a defined uptime commitment. And the exit path is known, which paradoxically is why they never need it.
Real Morweb clients across all four verticals run on these terms. Engineers Without Borders USA (nonprofit) and AAHomecare (association) manage their own content without per-change fees. The San Francisco School (education) and Promise Healthcare (healthcare) run on managed hosting with the platform accountable for uptime and security. In every case the relationship is structured so the organization holds the leverage: they can edit their site, export their data, and leave if they ever choose to. That structure is what a trustworthy vendor offers before you ask.
"The best signal that a vendor is trustworthy is how they answer the exit question. When an organization asks us how they would leave, we tell them plainly: export your content and data, take your domain, here is the format. A vendor confident in the value they deliver has no reason to trap anyone. The trap is what you build when the product cannot hold clients on its own."
- Murad Bushnaq, CEO & Creative Director
Common Mistakes Organizations Make Evaluating Vendors
Most vendor mistakes are made before the contract is signed, by focusing on the wrong things and skipping the questions that matter.
- Judging on design alone. A beautiful portfolio tells you nothing about data ownership, support, or contract terms. Evaluate the structure, not just the pixels.
- Trusting the pitch over the contract. Verbal promises about support and flexibility mean nothing unless they are in the signed document. Get every commitment in writing.
- Skipping the exit question because you just started. The best time to understand how you would leave is before you join, while the vendor is still earning your business.
- Ignoring the renewal terms. The termination and renewal sections are where the multi-year trap lives. Read them first, not last.
- Comparing sticker prices instead of total cost. A low headline price with per-change fees and required vendor support can cost more than a higher all-in price. Compare total cost of ownership.
Nonprofit Website Vendor Red Flags: Common Questions
What is the biggest red flag when hiring a website vendor?
The inability to export your content and data. If a vendor cannot tell you exactly how you would take your pages, images, and member or donor data out of their platform, in a standard format, guaranteed in the contract, you do not own your website. Data portability is the single most important term, because it is also the protection against every other risk: price increases, poor support, acquisitions, and lock-in.
What questions should I ask a website vendor before signing?
Ask five things directly: Can our staff make routine changes ourselves at no extra cost? What triggers additional charges? How does renewal and cancellation work, and can prices increase? What is the full process for leaving, and what do we take with us? What is your guaranteed support response time and who provides it? Get every answer in writing in the contract, not in the sales conversation.
What does "you own your content" actually mean?
It means you can export your pages, posts, images, documents, and structured data (members, donors, events) in a standard, usable format, at any time, without needing the vendor's permission. If the vendor cannot show you the export capability or name the file format, the phrase is marketing language, not a real ownership right. Insist that export rights are written into the contract.
Is per-change billing always a bad sign?
Billing for substantial new work, like building a new section or a custom feature, is normal and fair. The red flag is billing for routine content edits: changing a photo, updating an event, editing text. If your own staff cannot make everyday changes without generating an invoice, the site will go stale because keeping it current costs too much, and you are dependent on the vendor for basic maintenance.
How do I protect my organization if a website vendor gets acquired?
You cannot prevent an acquisition, but you can make it survivable. The protection is data portability: if you can export your content and data at any time in a standard format, a vendor being sold or discontinuing the product becomes an inconvenience rather than a crisis. Look for contractual continuity terms, and above all confirm you can leave with everything you own.
Should I avoid proprietary platforms entirely?
No. Proprietary platforms often deliver more value with less maintenance than open-source alternatives, especially for teams without technical staff. The issue is not proprietary versus open source. It is whether the platform gives you a known, reasonable exit path and full data portability. A proprietary platform you can leave cleanly is safer than an open-source one you cannot maintain.
More on choosing and evaluating a website partner:
The Nonprofit Web Design Agency Guide. How to evaluate a design partner's expertise and fit, the companion to this post's focus on contract terms.
The Real Cost of a "Free" Website Platform. The time-cost audit framework for comparing total cost of ownership, not just sticker price.
About to sign a website contract?
Send us the contract and the vendor's answers to the checklist above. Our team will flag the terms worth negotiating, the questions still unanswered, and the clauses that could trap you later. You will get a straightforward read before you sign, not after. No pitch unless you ask for one.
