5 Biggest Cost Drivers of Nonprofit Website Projects

Folks often ask us, “What are the things that can make website redesign and rebuild projects more expensive?”

The quick answer: things that take up a lot of time.

The longer answer: over many years and hundreds of projects, we can tell you exactly what the biggest cost drivers usually are. Here are our top 5 hits:

1. Design & Development
2. Stakeholder Wrangling, Internal Capacity, & Timeline
3. Content Migration
4. CMS: Drupal vs WordPress
5. Transactional vs Consultative Partnerships

There are ways to save time and cost in some of these areas; others can’t be cut. Let’s dive in and explore each a bit more.

1. Design & Development

“Website design” encompasses many areas, including information architecture and content modeling. But here, we’re focusing on the aesthetic elements that make a website pretty and usable: fonts, colors, page layouts at different device widths, photos, illustrations, icons, UX (user experience) patterns, animations, interactivity, etc. Design can take up a lot of time! Why? There are a few reasons. 

Creating a visual design for the interactive medium of the web is its own discipline, and requires a special constellation of skills. Designers need time to synthesize user research, get to know an org and its brand, and understand the nature of a site’s content.  

Once a site design begins coming together, it’s usually presented via “comps” (pretty pictures of a web page that aren’t yet built in code). Comps let designers iterate more rapidly and get design approval (which can also add time, see below re: “cat herding”) before development work begins.

When development begins, the amount of time it will take to build the design can be summarized as “more variations, more time.” Some examples: 

• More page layout variations will take more time to build. If you have six different landing pages, giving each one a bespoke, artisanal, completely unique layout will take more time than consolidating your landing pages to conform to one or two shared layout patterns. 
• Animations and interactivity often need a lot of thought and troubleshooting to ensure they’re accessible and working on desktop and mobile, and require time for testing on a variety of mobile and touch devices.
• A design with many custom elements that can be combined in many different ways, like mix-and-match Lego blocks for creating web content, means developers need to test all of the permutations and combinations of those elements at different screen widths. More variations, more problems (and, of course, time).

On the bright side, keeping website designs more consistent can provide a better user experience overall and reinforce an org’s visual brand. A simpler design can be made more complex in the future, and herein lies an opportunity for savings. 

If you’ve got a tighter budget limit than you’d like, can you save cost on design? And if so, how?

Stay Flexible, Consider an MVP

If you want a more complex and/or interactive design than you can afford, the great news is that a well-built, well-designed site is made to be enhanced in the future. Approaching your project in phases is the best way to build a site on a limited initial budget. 

A good project partner will help you define an “MVP”, or “minimum viable product” (which should be called a “minimum lovable product”), to launch. This may mean starting with a smaller number of page layout patterns, and adding more later, or saving complex animations for post-launch enhancements. When we work with clients this way, we recommend trade-offs based on a particular org’s project priorities. We maintain a wish list of enhancements as we build the MVP, and then we can help orgs address their wish list items in the future, as more funds and time become available. 

2. Stakeholder Wrangling, Internal Capacity, & Timeline

Stakeholders: like cats, you gotta love them. Ok, maybe you don’t like cats. But you’ve probably heard that herding cats is extremely difficult, and wrangling stakeholders around website redesign and rebuild decisions is often compared to “herding cats”. 

There are many decision points in a website redesign and rebuild project: content and site structure changes, aesthetics, and functionality. Who in your organization will need to weigh in on these decisions? How will final decisions be made? The process of getting internal consensus and sign-off on decisions can take time. 

When you engage an expert team to help you design and build a site, they need to stay engaged throughout the project to deliver well. A longer timeline means more hours and more cost. 

A web project is also a lot of work for internal org staff. When you’re working with a good project partner, they bring web design and development expertise to the table, but you are the subject matter experts on your content, your work, your mission. You will need to write new content for your site, rewrite existing content, help migrate content, and/or help clean up script-migrated content. If you have events and other mission-critical work in addition to your website project, and your team is low on capacity to meet your project deadlines (i.e. getting sign-off on a decision, entering new content into a new design, etc.), this can also make project timelines longer.

There’s a caveat here: a project can be more expensive because its timeline is too short. There’s definitely a magic spot where your internal capacity to keep things moving along is in alignment with an affordable, steady development pace. A good project partner will work with you to map out that sweet-spot timeline.

If you’ve got a lot of internal stakeholders to wrangle, or limited internal capacity, how can you help a project stay on schedule?

Empower a Client Lead

A great client lead consolidates feedback from the web project team and other stakeholders to deliver back to your project partner. This person should have the power to finalize big decisions, make smaller decisions on their own, and enlist help from other internal staff members as needed. At DevCollab, we’ve found this role to be so important to keeping costs down that we require a client lead on every project.

3. Content Migration

If you’re redesigning and rebuilding a site that currently exists, and you plan to keep any of the content, that content needs to move into its new content management system (CMS) home during the development process. If an older site has a large volume of content, it can be more efficient to do this via computer scripts: developers write little computer robot friends that automatically grab the content from your old site and funnel it into the structures on your new site.

Sounds great, right? But, if your legacy content is complex, you’re changing a lot about it (i.e. its field structure, the way it’s entered into the CMS), or there are thousands of pages that need to be moved, and/or your site is very old, the content migration robot friends we build for you will need to be more complex. This can drive up costs a great deal.

Well, like, what if we need to do other things with our limited budget besides having you craft us expensive content migration robot friends?

Consider Some Manual Migration

Even when content migration is scripted, there’s manual clean-up that a project partner will need you, as the experts in your content, to do. If you’re doing content strategy, writing new content, or rewriting legacy content, a human will need to do that by hand, too. 

There’s almost always some manual content work to be done on any big website project. When scripted content migrations are too costly, and the volume of content isn’t overwhelming (only a few hundred to a few dozen pages), some organizations choose to do some or all of the migration by hand, copying and pasting it into the new site, rather than have developers spend time and budget on scripts (robot friends). 

Entering content into your new site is also a great way to test and learn the new editing interface. If you have staff capacity to manage interns, or a junior staff member will regularly be doing content entry on the site, organizing a copy/paste party can be a way to spare some of your project budget. (Interns often do at least need pizza, though, so keep that in mind.)

4. CMS: Drupal vs WordPress

“WordPress is cheaper” is something we hear all the time. But we can tell you that it’s not always cheaper in the long run.

This is for another day, but, if you need the flexible, robust functionality Drupal offers out of the box, recreating it in WordPress may save you money during the initial build. But building too much Drupal-like functionality in WordPress can lead to the codebase being more brittle, and therefore more costly to enhance and maintain over the long term. 

On the other hand, if you only have a small handful of content types, and are fine with building content relationships only via categories (taxonomy), maybe you don’t need Drupal at all. In that case, WordPress may be a more cost-effective option for you. 

So wait, WordPress is cheaper than Drupal, right?

Let an Expert Help With CMS Selection

If you’re unsure which of the two best open source CMS platforms is best for you, an excellent, collaborative project partner can help you figure out what the most cost-effective choice may be. 

This brings me to our final, most important cost driver.

5. Transactional vs Consultative Partnerships

Some web development partners have a more transactional approach to projects. They listen to what you need and want, square that with your budget, and then go away for a while and make your website. Then they’ll present it to you, get feedback, and go away again to fix or add the things you’ve asked for until everyone feels it’s ready to launch. 

There’s nothing wrong with this transactional type of relationship, but we’ve found that it tends to produce sites that “scratch the itches” your team presented to developers initially, but isn’t built with the bigger picture in mind. 

How do I find a partner who’s looking out for my long-term bottom line?

Partner with a Nonprofit Web Expert, Don’t Cut Corners Here

The best sites we work with are the ones that were produced via collaborative partnerships between the development teams and the orgs. Whether we originally built them or not, these sites are easy for us to build upon. This is why working with a partner that specializes in nonprofit sites can be extremely helpful, as they have a deep understanding of funding cycles, capacity issues, sustainability concerns, and other kinds of business challenges specific to nonprofits.

A good consultative partner will advise you on building a site that will last as long as you need it, and will plan for your long-term goals, as well as scratching those immediate itches. They will push you to prioritize users over internal org politics, and defend accessibility throughout the project. 

More collaboration means more discussion, communication, and sometimes developers saying no to requests that make a site less sustainable for your org, or less accessible or usable for your audiences. This style of working together takes more time than “throwing things back and forth over a wall” in a more transactional way. 

Taking time to plan your site in a holistic, strategic way will be time well-spent when the outcome is a flexible site that can be built upon for years to come. This is far better than ending up with a bespoke, overly complex site that is costly to maintain and may need to be scrapped and rebuilt prematurely. That’s why this is not the place to cut corners.

And yes, you guessed it, DevCollab is a consultative project partner. And that means we’re not necessarily the cheapest and fastest web development team out there. That’s by design. It also means we sometimes have limited space to take on projects. But we’ve got many business-friends out there who are consultative in their approach to web projects, too, and we’re happy to make referrals if we’re not a good fit for your particular needs or timeline. Just reach out and drop us a line.

Back to top