8 Tips for Building a NonProfit Website On Time and In Budget

Web development projects can involve complex requirements, tight timelines, and unexpected roadblocks that can make it difficult to get what you want on time and within budget. Having worked with a number of non-profits over the last 12+ years, Code Koalas has seen what threatens website projects to go off the rails and learned a number of strategies to keep them  running on track. I’ve done my best to condense those learnings into these 8 practical tips that I think can help you with your projects.

Always Have a Developer in the Room (aka Technical Discovery)
Most website projects involve some kind of discovery; from figuring out your preferred aesthetic, to determining personas and auditing content. But often technical people and questions get left out at the beginning of the project, causing a scramble later in the project when budgets and deadlines have already been set. When we work with non-profits we have our developers join in at the beginning of the project to make sure these difficult questions get asked. Then we turn those into detailed user stories to make sure none of the behind the scenes pieces get lost in the project shuffle. Here’s a few questions to make sure get answered in a website discovery to help set a good budget and keep surprises to a minimum:

• Who within your organization logs into your website and what do they do? (Create content, download form submissions, print reports, manage users, etc)
• Who owns and is responsible for your domain name and DNS changes?
• What 3rd party applications currently integrate into your website or need to? (CRM, email marketing, billing/ecommerce, donor portal, etc)
• Are any of those applications changing between now and launch?
• Are there security or IT requirements that must be met with your new site? 
• Even better: Who can we chat with in IT to make sure we’re meeting all their needs and requirements for launch?
• Are you wanting to migrate content in an automated way, or manually?

Keep the Designer In Check…list
Often it isn’t until you start building a website or start entering content into it that you realize that some design choices just don’t work in the real world. At Code Koalas we developed our own Innocuous Design Fail Checklist to consolidate our learnings from each project and make it easy to catch those errors in the future, ahead of time. Here are a few you can use to make sure your website designs won’t have trouble later:

• Is there bare text over images that only works because of the specific images in this design?
• Are styles applied to 3rd party components or iframes that we don’t have style control over?
• Are titles character limited or does the design show and accommodate multi line titles? Mobile and Desktop?
• Are there bare icons/logos that need descriptive text for unfamiliar users?
• Does the mobile menu account for getting to top level pages when there is sub menu navigation?

Agree Early on What is Critical
Sometimes things outside of anyone’s control happen (sickness, purchasing delays, IT) and suddenly you find yourself needing to launch your website in 2 weeks, but there’s 4 weeks of work remaining. To avoid this situation, prioritize the project features at the beginning with your agency. We like to break things down into Must Haves, Should Haves, and Nice to Haves. That way when you get down to the wire on budget or deadline it's easy to clear out the Nice to Haves, and an easier conversation with stakeholders if you need to prune some Should Haves as well. Making sure your partner hits the Must Haves first means you won’t have to explain why your website has its very own version of Clippy, but none of the contact forms feed into the CRM.

First We Party, 3rd Party
Don’t leave integrations to the end, even simple ones. These are the biggest areas of projects that rely on people outside the project and are very difficult to speed up. You don’t need to fully build out integrations at the beginning, but you do need all of the information and access to run meaningful tests at the beginning of the project. Too often I’ve seen projects delayed because the “person who handles that” is unavailable for weeks or simple integrations take weeks for a 3rd party to get around to provisioning. Front loading this means you should have everything you need by at least the middle of the project. That’s important because sometimes these integrations just don’t work the way you expect them to, which is much better to figure out and pivot early in the project than at the end.

Who, What, When, Where of Content
In any web project, especially particularly technical projects, content can get put on a back burner and ultimately postpone a site launch. Establishing who is responsible for what content, where they’re putting and by when is a critical part of any website project plan. Clear deadlines need to be set for when a website launch will get pushed because content is not created or entered yet, especially when content creation is handled by someone internally. An often missed point is collaborating with the site developers to determine when the site will be ready to enter content. Make sure there is more than a couple days between when users can actually use the website to start entering/editing content and when it needs to be done.

Seeing is Believing
You can’t QA what you can’t see.  While it is nice to dive into complex backend work and deal with the scary things first, the reality is that you don’t know if those complex problems are solved until someone can QA it. So make sure the front end gets at least roughed in first and weeks or months aren’t spent working on the backend before anyone besides the developers can take a look at what the code does. This can help keep your anxiety level down as you can see progress and give feedback a few bugs at a time. Leaving all QA to the end can be overwhelming for everyone involved, so make sure your developer and project plan don’t force that on you.

A Quiet Place 
Last minute changes kill launches. From simple code changes, to quick copy swaps, I’ve seen the smallest of changes bring an entire site down or break previously tested key functionality. To avoid this we set content/code freeze dates or quiet periods at the end of our projects before launch, usually about a week out from launch. This gives everyone time to review, test and agree that the site is ready for launch without rushing to get as much in before launch as possible. If an issue is found during this time, we decide if it's critical enough to fix and push the launch date back, and if it is not, we log it into a post launch fix backlog. This makes sure when you launch your site and tell all the important people about it, they see a great new website and not a glaring error introduced by several last minute changes that didn’t play nice with each other.  

Plan to Be Surprised
No one starts a website development partnership expecting it to go south, but you should make a plan just in case. From a freelancer ghosting, to family emergencies or developers quitting with no notice there is a lot that can throw a wrench in your well planned project. We’ve rescued many non-profit website projects that started well and then stalled out for various reasons. Your first step in a contingency plan is to already have at least one and maybe a couple backup development partners available, before you need them. Next you’ll want to set some development milestones throughout the project that make sense to you, so you can know when your website project is getting off track well before the delivery date. I’d also recommend setting a contingency drop dead date, that is the last day you can enact a contingency plan and realistically still expect to hit your deadline. To determine that date I would halve your original development timeline with the assumption that your contingency partner can double the resources you originally planned on, add a week for contracting / onboarding, and then count back from your QA delivery date.  

Whether this is your first website project or you’ve endured many difficult website builds, implementing a few of these tips should help you have a smooth website development experience. If you have questions, are struggling with your own website project, or are looking for a solid non-profit website development partner; I’m happy to grab a coffee or zoom meeting to see how I can help!