What does a nonprofit website redesign actually cost?

This is the question everyone has and nobody wants to ask out loud, because the answer they’ve heard before is either “it depends”—which is both technically true and completely unhelpful—or a number that made them close the browser tab.

So let’s actually talk about it. Not in the abstract, but honestly: what does a nonprofit website redesign cost, what drives that cost, and how do you know if what you’re being quoted is fair?

The range is wide, and that’s not an accident

Website pricing spans an enormous range, and the reason isn’t arbitrary. A website can be almost anything—a simple four-page brochure site or a complex platform with custom integrations, member portals, and a content management system that serves fifty staff members. The same word covers wildly different things.

That said, here’s an honest picture of the market:

At the low end, under $500, you’re in DIY or volunteer territory. Someone on the board offers to build it, or a well-meaning volunteer puts something together over a weekend, or you use a template and fill it in yourself. Sometimes this works fine for an organization in its earliest stages with very simple needs. More often, it produces a site that doesn’t quite represent the organization, that nobody fully understands how to manage, and that becomes increasingly embarrassing over the next three years as staff turnover means institutional knowledge about it quietly disappears.

In the mid-range—roughly $3,000 to $10,000—you’re typically working with an experienced independent designer or small studio. This is where I work, with projects starting at $5,000 for a Squarespace build. At this level, you’re paying for someone who does this full time, who brings strategic thinking to the project, who has opinions about what works and what doesn’t, and who is going to ask you a lot of questions before touching a single design element.

At the higher end—$15,000 to $25,000 and above—you’re usually working with an agency, or with an independent designer on a complex custom build. Complex WordPress implementations, custom-developed features, large content migrations, and sites with significant technical requirements can legitimately reach these numbers. The price reflects the scope, not necessarily the quality.

What you’re actually paying for

When people see a $5,000 quote for a website and think “that seems like a lot,” they’re usually picturing the end product—a website—and not the process that produces it.

Here’s what that process actually looks like on my end, before a single page gets designed:

Understanding the organization. What do you do, who do you serve, how do people find you, what do they need when they get there, what are you trying to communicate, what’s not working about what you have now? This isn’t small talk—it’s the research that determines whether the final site actually solves the right problem.

Deciding what the site needs to contain. How many pages, what goes on each one, how does content flow between them, what forms are needed, how are resources organized, what’s the hierarchy of information? These decisions take time and require back-and-forth.

Thinking through content. Who's writing it? If you are, great—but writing for the web is a specific skill and most organizations underestimate how long it takes. If I’m doing it, that’s additional scope. If you’re doing it and it comes in as a wall of text that reads like a grant application, someone is going to need to reshape it, and that someone is usually me.

Only after all of that does design and build actually begin.

The point is that a website project is a collaborative process that requires a significant investment of time from both sides. Organizations that go in expecting to hand off a brief and receive a finished product six weeks later tend to have a difficult time, regardless of who they hire.

The things that drive cost up

Beyond the baseline, a few things consistently add to the scope and price of a redesign:

Content migration. If you have an existing site with years of blog posts, resources, or archived content that needs to move to the new site, that’s a significant amount of work that people consistently underestimate. It’s not just copying and pasting—it’s reviewing, organizing, reformatting, and making decisions about what’s worth keeping.

Third-party integrations. Donation platforms, CRM systems, event registration tools, email marketing software—connecting your website to outside systems takes time, and sometimes the integration is less seamless than the tool’s marketing suggests. A surprising amount of integration work ends up being custom CSS to make a third-party donation form look like it belongs on your site, rather than like it was embedded from a different decade.

Copywriting. If you want help writing the actual words on your site—and most organizations do, even if they don’t realize it upfront—that’s typically scoped separately. DIY copywriting is almost always the thing that slows a project down the most and produces the result people are least happy with.

Complexity of content structure. A site with five pages and a contact form is a different project than one with eight service areas, a resource library, staff directories, and multilingual content. Scope determines price.

The pattern I see most often

Here’s the thing about nonprofit web design that I think is worth saying directly: organizations tend to either want it to be cheap or assume it has to be expensive. Neither instinct serves them well.

The organizations that go cheap usually end up with something built by a volunteer or a board member who means well but isn’t a designer—or they hire someone at a surprisingly low price and get a site that looks like it cost what it cost. It goes live, nobody knows how to update it, it sits untouched for five years, and eventually they decide they need to redo it. At which point the cycle often repeats.

The organizations that assume expensive means quality sometimes hire an agency at $20,000, get a sprawling WordPress site loaded with plugins and custom code, and find themselves eighteen months later with a site that’s become a liability—slow to load, difficult to update, increasingly vulnerable to security issues, and requiring ongoing developer fees for every small change. The price tag didn’t guarantee the outcome.

The organizations that fare best tend to be the ones that think carefully about what they actually need, hire someone whose process they trust (not just whose portfolio they like), and go in understanding that their participation in the project is part of what determines the result.

A note on WordPress specifically

WordPress powers a significant portion of the web and can be the right choice for organizations with complex, specific technical requirements. But a lot of nonprofits end up with WordPress sites not because they needed what WordPress offers, but because it’s what their developer knew, or because “it's free,” or because it seemed like the powerful, future-proofed option.

A heavily customized WordPress site with a premium theme, ten plugins, and custom development is not cheap—it’s often more expensive to build than a well-designed Squarespace site, and considerably more expensive to maintain. The plugins need updating, the theme needs updating, the WordPress core needs updating, and if any of those updates breaks something (which happens), you need a developer to fix it. That ongoing cost is real and rarely factored into the initial conversation.

I'm not saying don’t use WordPress. I’m saying be honest with yourself about whether you need it.

So what should you budget?

If you’re a small to mid-sized nonprofit with a clear set of content needs—services, about, resources, contact, maybe a blog—and you want a site your team can actually manage, budget $5,000 to $10,000 for an experienced independent designer. Expect the process to take two to four months and to require meaningful time from your side.

If you have more complex needs—large content libraries, custom integrations, significant technical requirements—budget more, get detailed quotes, and ask specifically what’s included and what isn’t.

Whatever you’re quoted, ask the person you’re hiring what happens after launch. Who handles updates? What does ongoing support look like? What does your team need to know to manage the site independently? The answers to those questions will tell you a lot about whether you’re going to end up with something that works for the long term or something that needs to be completely redone in five years.

If you’d like to talk through what a project might look like for your organization—scope, timeline, what to expect—I’m always happy to have that conversation before anyone commits to anything.

How to audit your nonprofit website for privacy risks.

Most nonprofit leaders assume their website is basically fine from a privacy standpoint. They have a privacy policy somewhere in the footer, they’re not selling data, and they’re not doing anything sketchy. What more is there to think about?

Quite a bit, it turns out—and most of it is invisible unless you know where to look.

Your website is probably collecting more data than you realize, sharing it with more third parties than you’d expect, and retaining it longer than is necessary. None of that is unusual, and none of it means your organization has done something wrong. It means you’re using tools that were built to collect data by default, and no one has gone back to examine what’s actually happening under the hood.

This post walks you through a practical self-audit you can do without a technical background. You don’t need to understand code. You just need to know where to look and what questions to ask.

Step one: find out what’s loading on your site

The first thing to understand is what third-party scripts are running on your website. Every time someone visits your site, their browser loads not just your content but potentially a collection of scripts from other companies—analytics tools, social media platforms, advertising networks, embedded widgets, font libraries. Each of those is a data relationship you’ve entered into on behalf of your visitors, whether you meant to or not.

To see what’s running, open your website in Google Chrome or Brave Browser, right-click anywhere on the page, and select “Inspect.” Click the “Network” tab, then reload the page. You’ll see a list of everything loading—look specifically at the entries that aren’t your own domain. You’re looking for things like google-analytics.com, facebook.net, doubleclick.net, platform.twitter.com, or any other third-party domains.

If that feels too technical, a simpler option is to use a tool like Blacklight (themarkup.org/blacklight) — paste in your URL and it gives you a plain-language report of the trackers, ad networks, and third-party scripts it detects on your site. It was built specifically to make this kind of information accessible to non-technical people, and it’s free.

Once you know what’s loading, you can start making decisions about what should stay and what should go.

Step two: evaluate each third-party tool

Not all third-party scripts are equal. Here’s a framework for thinking through each one:

Do you know it’s there? Sometimes scripts end up on a site through an embedded widget, a social sharing button, or a plugin someone installed years ago without fully understanding what it did. If you’re not sure why something is loading, that’s worth investigating before you decide whether to keep it.

What data does it collect, and where does it go? Analytics tools collect visitor behavior. Social pixels collect information about who visits your site and share it with advertising platforms. Embedded maps and video players may collect location and viewing data. Each tool’s privacy policy will tell you what it collects—though reading those is its own adventure—and whether that data is shared with or sold to third parties.

Is it necessary? This is the most important question. For every third-party tool on your site, ask what you’d lose if you removed it. If the answer is “not much,” remove it. If it’s serving a purpose, ask whether there’s a less data-intensive way to serve that same purpose.

Social media sharing buttons are a common example of tools that feel useful but aren’t worth the tradeoff. The buttons themselves load scripts from Facebook, Twitter, and other platforms that track every visitor who lands on the page—regardless of whether they click the button. A plain text link to share something accomplishes the same goal without the tracking infrastructure.

Step three: look at your analytics setup

If you’re using Google Analytics, there are a few specific things worth checking.

First, confirm you’re using GA4 rather than the older Universal Analytics. GA4 anonymizes IP addresses by default, which is a meaningful baseline privacy improvement.

Second, check your data retention settings. In GA4, go to Admin > Data Settings > Data Retention. The default is two months for user-level data, which is reasonable—make sure it hasn’t been changed to a longer period without a clear reason.

Third, look at whether Google Signals is enabled. Google Signals connects your analytics data to Google’s advertising network, enabling cross-site tracking and behavioral targeting. For most nonprofit websites, this feature serves no purpose and should be turned off. You’ll find it under Admin > Data Settings > Data Collection.

If you’re open to switching analytics tools entirely, privacy-focused alternatives like Plausible or Fathom collect only what you actually need—page views, referral sources, popular content—without the broader data collection that comes with Google’s ecosystem. They’re not free, but they’re not expensive, and the tradeoff is worth considering for organizations serving vulnerable populations.

Step four: review your forms

Your contact forms, intake forms, and newsletter sign-ups are some of the most sensitive data collection points on your site. A few things to check:

What platform is handling your forms? If you’re using Google Forms, your submissions are stored in Google’s infrastructure. If you’re using Typeform or JotForm, your submissions are in their databases, under their privacy policies. Native form tools built into your website platform—like Squarespace’s built-in forms—typically give you more control over where data goes and who can access it.

Where do submissions go after someone fills out a form? Most platforms send an email notification, store the submission in a backend database, or both. Check whether submissions are accumulating in your platform’s backend without anyone actively managing or deleting them. Old form submissions are data you’re responsible for—and data you’re not actively using is data you probably shouldn’t be keeping.

How long do you keep form submissions? If you don't have an answer to this question, that’s the gap to close. A simple retention policy—“we delete intake form submissions after 90 days unless they've been transferred to our case management system”—is better than no policy, and it protects your clients.

Step five: check your privacy policy

Your privacy policy should accurately describe what your site actually does—not what you intended it to do when the policy was written, but what it does right now. If you’ve added tools or changed platforms since the policy was last updated, it may no longer be accurate.

At minimum, your privacy policy should cover: what data you collect and why, what third-party tools you use and what they collect, how long you retain data, and how someone can request that their data be deleted. It should be written in plain language, not legal boilerplate, and it should live somewhere easy to find—not buried at the bottom of a page nobody visits.

A privacy policy that doesn’t reflect your actual practices isn’t just a document problem. It’s a trust problem.

What to do with what you find

A privacy audit isn’t meant to produce a perfect score—it’s meant to give you a clear picture of where you are, so you can make deliberate decisions about where you want to be. You might find that most of your setup is fine and there are two or three specific things to address. You might find a tracking pixel that got added during a social media campaign and was never removed. You might find that your analytics data retention is set to something nobody consciously chose.

Whatever you find, the goal is the same: make sure the data your website collects is the data you’ve decided to collect, for reasons you can explain, handled in ways you’ve thought through.

If you’d like help working through this audit—or want someone to do a more thorough technical review—that’s work I do with organizations regularly. Sometimes a second set of eyes finds things that are easy to miss when you’re close to the work.