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.

Squarespace for nonprofits: is it the right platform for your organization?

If you’ve ever gone looking for advice on which website platform to use, you’ve probably encountered some version of the same conversation: someone recommends WordPress because it’s powerful and free, someone else warns that it’s a nightmare to maintain, someone mentions Wix or Weebly, and then everyone piles on to explain why those aren’t great either.

It’s a genuinely confusing landscape, and the stakes feel high—your website is often the first thing people encounter when they’re looking for help, so getting the platform wrong has real consequences.

I’ve been building websites for nonprofits and advocacy organizations for a long time, and I work primarily in Squarespace and Webflow. This post is specifically about Squarespace—what it does well, where it runs into limitations, and how to think about whether it’s the right fit for your organization.

What Squarespace is

Squarespace is an all-in-one website platform—hosting, design tools, domain management, analytics, and form handling are all bundled together. You pay a monthly or annual fee and get a fully managed environment. You don’t install software, manage server configurations, or worry about keeping plugins up to date.

That bundled model is both Squarespace’s biggest strength and the source of most of the criticism you’ll see of it. You get a lot out of the box, but you’re working within the constraints of what Squarespace has built. Whether that’s a good trade depends almost entirely on what your organization actually needs.

Where Squarespace excels

Security—and I don’t think this gets enough credit. Squarespace handles security at the infrastructure level. SSL is included and automatic. The platform manages its own updates, patches vulnerabilities, and protects against common attacks without you having to do anything. There’s no plugin ecosystem introducing new vulnerabilities every time someone pushes an update.

This is a meaningful consideration for organizations handling sensitive client information. A WordPress site loaded with plugins—which describes the majority of nonprofit WordPress sites I’ve encountered—has a much larger attack surface. Each plugin is a potential entry point, and plugins that aren’t regularly updated become liabilities. I’ve seen organizations get hacked through an outdated contact form plugin, a neglected SEO tool, a theme that stopped being maintained. That’s not hypothetical—it’s common.

With Squarespace, that category of risk largely disappears. For organizations serving vulnerable populations where a data breach would be truly harmful, that’s not a small thing.

Privacy by default. Squarespace’s built-in analytics are relatively lightweight—you get traffic data without the surveillance infrastructure of Google Analytics. Form submissions are primarily handled via email notification rather than stored indefinitely in a database, which means sensitive intake information isn’t accumulating somewhere you’ve forgotten about. You can configure session data not to be stored. SSL and domain privacy are standard. None of this requires technical expertise to set up—it’s just how the platform works.

Accessibility out of the box. Squarespace templates are built to modern standards, with clean semantic structure, good keyboard navigation defaults, and straightforward image alt text fields. You’re not starting from zero on accessibility, which you often are with a custom WordPress theme or a heavily modified template. That said, Squarespace isn’t a substitute for thoughtful design decisions—you can still make inaccessible choices within an accessible framework—but the foundation is solid.

Your team can actually manage it. This is underrated. Squarespace’s drag-and-drop editor, layout suggestions, and visual interface mean that a non-technical staff member can update content, add pages, and make design changes without breaking anything or needing to call a developer. That matters enormously for organizations with limited budgets and high staff turnover.

I’ve encountered WordPress sites where the client was actually afraid to log in and make changes. That’s not a hypothetical—it’s one of the most common things I hear from organizations who come to me after a bad experience. “We have a developer who built it but we can’t afford to keep paying them for every little update, and no one on staff knows how to touch it.” Squarespace largely solves that problem.

The real cost comparison. Squarespace’s pricing looks expensive compared to “free WordPress”—but that comparison isn’t honest. A WordPress site in practice means paying for hosting (typically $10–30/month for something reliable), a premium theme ($50–200/year), and an assortment of plugins for forms, SEO, security, backups, and performance (which can easily add another $100–300/year). Then there’s the ongoing cost of maintaining all of it—updates, troubleshooting, the occasional developer call when something breaks. When you add it up, Squarespace’s annual plan often comes out cheaper than a properly maintained WordPress setup, and significantly cheaper than one that’s been patched together over several years.

Where Squarespace has limitations

Complex, deep content structures are harder to manage. Squarespace works beautifully for organizations with a clear, relatively contained set of pages—services, about, resources, contact, blog. Where it gets harder is when you have a large resource library with multiple levels of categorization, complex navigation hierarchies, or a lot of content that needs to be organized in sophisticated ways. The platform’s content management tools are simpler than WordPress’s by design, and at a certain scale of complexity, that simplicity becomes a constraint.

If your organization has dozens of programs, several distinct service areas with their own sub-pages, or a content-heavy site that functions more like a database than a brochure—Squarespace may not be the right fit, and Webflow or a well-built WordPress site might serve you better.

Custom functionality has limits. Squarespace has a robust set of built-in tools, but if you need something very specific—a custom intake workflow, complex membership features, integration with a specialized case management system—you’ll hit the edges of what the platform can do. Extensions exist, but the ecosystem is much smaller than WordPress’s. For most nonprofit websites, this isn’t a problem. For organizations with highly specific technical requirements, it might be.

You’re on Squarespace’s timeline. When Squarespace changes something—updates the editor, deprecates a feature, changes how templates work—you adapt. You don’t control the infrastructure. For most organizations this is fine, and the tradeoff (not having to manage the infrastructure yourself) is worth it. But it’s worth knowing that the platform has made significant changes in the past that required existing sites to update.

So is it right for your organization?

Squarespace tends to be a great fit for nonprofit organizations that have a clear, contained set of content and services, want their team to be able to manage the site without ongoing developer dependence, care about security and privacy without wanting to manage those things themselves, and don’t have highly specialized technical requirements.

It tends to be a harder fit for organizations with large, complex content structures, very specific custom functionality needs, or technical teams who want full control over the infrastructure.

If you’re currently on WordPress and your site is stagnant because nobody feels confident updating it, that’s a real problem worth solving—and a platform change might be part of the answer. If you’re on Wix or Weebly and wondering if there’s something better, there almost certainly is.

If you’re not sure which platform makes sense for your organization’s specific situation, that’s exactly the kind of question I help organizations think through—before they commit to a build. Feel free to reach out and we can talk it through.

Are your intake forms putting your clients at risk?

Intake forms are one of the most important pieces of infrastructure on your organization’s website. They’re often the first real interaction someone has with you—the moment a person in a difficult situation decides to share something personal and ask for help.

They’re also, in many organizations, one of the least examined pieces of infrastructure on the site. The form was built when the organization launched, or when someone switched platforms, or when a volunteer with some web skills offered to help. Questions got added over time. Nobody ever went back to ask whether all of them should still be there.

This post is an invitation to do that—to look at your intake forms not just as a functional tool but as a data collection decision, and to think carefully about whether what you’re collecting serves your clients or creates risk for them.

The basic question: do you need this?

Every field on your intake form is a piece of data you’re responsible for. It gets stored somewhere—in your platform’s database, in an email notification, in a spreadsheet someone exported once and forgot about. It can be accessed by people inside your organization, and potentially outside it. It persists until someone deliberately deletes it, which in many organizations means it persists indefinitely.

The principle of data minimization says: only collect what you actually need, for a specific purpose, and only keep it as long as that purpose requires. It sounds simple, but it runs counter to how most forms get built, which is additive—fields get added and rarely removed.

A useful exercise is to go through your intake form field by field and ask two questions: what do we do with this information, and what would happen if we didn’t collect it? If the answer to the first question is “not much” and the answer to the second is “nothing significant,” that field probably shouldn’t be there.

Some of the most common fields worth reconsidering:

Full date of birth. If you need to verify someone is over 18, a checkbox confirmation does that job without creating a record of someone’s exact birthdate. If you need age for service eligibility, an age range works just as well.

Full home address. For many organizations, a general service area or zip code is all that’s actually needed for intake purposes. A full address is sensitive—particularly for someone fleeing an unsafe situation—and storing it creates responsibility.

Demographic details that aren’t tied to service delivery. Race, ethnicity, income level, and household composition are sometimes collected for grant reporting purposes, which is legitimate. But if you’re collecting them by default on every intake form without a clear reporting need, it’s worth asking whether that’s the right place to gather that information, and whether it could be collected separately and anonymously.

Open text fields with no guidance. “Tell us about your situation” sounds welcoming, but it’s an invitation for people to share more than you need—and more than is safe for them to have in a form submission. If you need some context, narrow the question. “What kind of support are you looking for?” gets you what you need without encouraging people to disclose sensitive details upfront.

Who can see what gets submitted

This is a question a lot of organizations haven’t fully answered, and it’s worth sitting with. When someone fills out your intake form, where does that data go?

Most form submissions do at least one of the following: they get stored in your website platform’s backend, they get sent to one or more email addresses as a notification, or they get routed to a CRM or case management system. In many organizations, all three.

Each of those destinations has its own access controls, or should. Some questions worth asking:

Who receives the email notifications when a form is submitted? Is it a personal inbox, a shared inbox, or a role-based address? What happens to those emails—are they archived, deleted after a certain period, or just sitting in someone’s inbox indefinitely?

Who has admin access to your website platform or CRM, and when was that list last reviewed? Former staff or volunteers who still have access to form submissions is a more common problem than most organizations realize.

If your form submissions are being stored in your website platform’s backend—Squarespace, WordPress, or similar—are you periodically exporting and deleting old submissions, or are they accumulating? Many platforms store form submissions indefinitely by default, which means years of client data may be sitting in a database that nobody’s actively managing.

None of this requires a complicated technical solution. It requires a policy—a clear, written answer to “where does this data go, who can see it, and how long do we keep it”—and someone responsible for making sure that policy is actually followed.

How the form itself communicates trust

Beyond what you collect and how you store it, the form itself sends signals to the person filling it out. Those signals matter, especially for people who have reason to be cautious about sharing personal information.

A form that asks for a lot of sensitive information upfront, with no explanation of why it’s needed or what happens to it, can feel extractive—like handing over details to an institution that hasn't earned that trust yet. A form that’s transparent about what you’re collecting and why, that acknowledges the sensitivity of the information, and that tells people what to expect after they submit—that feels different.

Some practical ways to build trust into the form itself:

Add a brief note at the top explaining what the form is for and what happens next. “This form helps us understand your situation so we can match you with the right support. Someone from our team will be in touch within 48 hours.” That one sentence reduces anxiety and sets expectations.

If you collect sensitive information, explain why. “We ask for your zip code so we can connect you with services in your area” is more reassuring than a blank address field.

Include a privacy note near the submit button. It doesn’t need to be long—something like “Your information is kept confidential and shared only with the staff member handling your case” tells people what they need to know.

Be honest about what you can and can’t guarantee. If your organization has mandated reporting obligations, people deserve to know that before they share information that might trigger them.

A note on third-party form tools

If you’re using a third-party form tool—Typeform, JotForm, Google Forms, or similar—it’s worth understanding that those platforms have their own data storage and privacy policies, which may not align with your organization’s values or your clients’ expectations.

Google Forms, in particular, stores submissions in Google’s infrastructure and may use that data in ways that aren’t fully transparent. For organizations serving vulnerable populations, a form tool that stores data on Google’s servers is worth reconsidering. There are alternatives—Tally, Formspree, or native form handling built into your website platform—that give you more control over where submissions go and who can access them.

Where to start

If this post has made you want to look at your intake forms with fresh eyes, start with the simplest version of the audit: open the form yourself, read every field, and ask whether you’d be comfortable explaining to a client exactly why you need that information and what you do with it. If the answer to any field is uncomfortable, that’s a signal.

From there, trace where submissions go—email, platform backend, CRM—and make sure you know who has access at each step. Then set a retention policy, even a simple one, and make sure old submissions are actually being cleared.

It’s not a complicated process. It just requires intentionality—which is something your clients, who trusted you enough to fill out the form in the first place, deserve. If you’d like help thinking through your forms or your broader data handling practices, I’d love to hear from you.

What data should your nonprofit stop collecting right now?

Let’s start with something a little uncomfortable: most women’s rights organizations are collecting more information about the people they serve than they actually need. Not out of bad intentions—usually out of habit, or because the intake form was built years ago and nobody’s questioned it since, or because someone once said “we might need this later.”

But for organizations serving survivors of domestic violence, people seeking reproductive healthcare, or clients navigating legal systems that don’t always protect them—unnecessary data isn’t just a compliance issue. It’s a safety issue.

Here’s a practical look at what to reconsider.

The intake form problem

Intake forms are where most of the damage happens. They’re often the first point of contact between your organization and someone who may be in a vulnerable, high-stakes situation—and they tend to accumulate fields over time without anyone asking whether each one is actually necessary.

Some of the most common offenders:

Full date of birth—Unless you’re providing a service with a strict age requirement, you probably don’t need a full birthdate. What you usually actually need is an age range, or confirmation that someone is over 18. A full date of birth is a piece of personally identifiable information that can be used to locate or identify someone—and storing it creates risk.

Full legal name—This one is context-dependent, but worth examining. Many organizations default to collecting full legal names out of habit. If you’re providing services where legal name isn’t necessary—a support group, a resource library, a crisis line—consider whether a first name, or even no name at all, would serve just as well.

Gender and pronouns—This is a nuanced one. For organizations serving LGBTQ+ communities, collecting gender identity and pronouns can be important and affirming. But it’s also sensitive data—particularly for trans and nonbinary people in environments where that information could be used against them. If you collect it, be deliberate about why, how it’s stored, and who can access it.

Full home address—For survivors of domestic violence or people in unsafe housing situations, a home address is genuinely dangerous data to have sitting in a form submission or a spreadsheet. Ask yourself: do you actually need a full address, or do you need a general service area, or just a way to contact them? If you do need an address for service delivery, think carefully about how it’s stored and who has access to it.

Titles and honorifics—Low-stakes compared to the above, but worth noting—fields like “Dr./Mr./Mrs./Ms.” are often just vestigial form elements that collect gender information under a different label. If you don’t have a specific reason to collect this, remove it.

The “we might need it later” trap

One of the most common reasons organizations collect more data than they need is future-proofing. Someone once thought “it would be useful to know our clients’ income levels” or “we should track how people heard about us”—and now those fields live in the intake form forever, collecting data that nobody’s actually looking at.

The principle to apply here is data minimization: only collect what you actively use for a specific, defined purpose. If you can’t point to a concrete use for a piece of information, don’t collect it. Not only does this reduce your risk exposure, it also makes your forms shorter and less overwhelming for the people filling them out—which, for someone in a crisis, matters enormously.

A useful exercise: go through your intake form field by field and ask, for each one, “what do we do with this information?” If the answer is “nothing, really”—cut it.

The invisible data problem: your website

Intake forms are the obvious place to look, but your website may be collecting data you’re not even aware of.

Social media pixels. If you have a Facebook pixel, a TikTok pixel, or similar tracking code on your site, you are allowing those platforms to collect information about every person who visits your website—including people who may have come looking for help with a DV situation, an abortion, or immigration status. That data can be used for ad targeting, and in some cases may be accessible to third parties including law enforcement. For most women’s rights organizations, this is an unacceptable risk. Remove them.

Social sharing buttons. Even if you don't have a pixel, embedded social sharing buttons (the little “share on Facebook” icons) often load third-party scripts that track visitors. If you want people to be able to share your content, a plain text link does the job without the surveillance infrastructure.

Analytics tools. Most websites use some form of analytics to understand how people find them and what they do once they arrive. That’s legitimate—you need to know if your resources are being found and used. But not all analytics tools are created equal.

Google Analytics is the most widely used option, and if you’re already using it, the good news is that the current version (GA4) automatically anonymizes IP addresses by default—you don’t have to do anything to enable that. What you should do is check your data retention settings: GA4 defaults to storing user-level data for two months, and you can verify or reduce that in your property settings under Data Settings > Data Retention. You should also make sure Google Signals is turned off if you’re not actively using it, as it enables cross-site tracking and behavioral advertising features you almost certainly don’t need. Google has a number of privacy options available for Google Analytics, they just might need to be enabled/disabled (depending what they are).

If you’re setting up analytics from scratch, or considering switching, there are privacy-focused alternatives worth knowing about. Plausible and Fathom are both cookie-free, don’t collect personal data, and are fully GDPR-compliant by design. They give you the traffic information you actually need—where people are coming from, which pages they visit, what’s working—without the broader surveillance infrastructure. Both have paid plans starting around $9–15/month, which for most small organizations is a reasonable trade for significantly better privacy posture.

Where to start

If this feels overwhelming, don’t try to fix everything at once. Start with your intake form, because that’s where the most sensitive data lives and where your risk is highest. Go field by field, apply the “what do we do with this?” test, and remove anything that doesn’t have a clear answer.

Then take a look at your website’s third-party scripts—most platforms make it relatively easy to see what’s loading. If you see social pixels, remove them. If you’re not sure what’s there or how to evaluate it, that’s exactly the kind of thing I can help with. Get in touch and we can take a look together.

The goal isn’t a perfect system. It’s a deliberate one—where every piece of data you collect is there for a reason, and the people you serve aren’t carrying more risk than they have to.