How to write a website brief for a grant project: what NGOs need to cover

If your grant project includes building a website, a description like "we need a modern NGO website" won’t be enough.

A technical brief helps you pin down exactly what the contractor has to deliver, by when, and for how much. There’s even a saying in the industry: no clear brief, no clue what you’ll get. Without one, the contractor just guesses at what "good" looks like — and not every contractor has worked with grant-funded projects before.

What the brief should cover

1. The site’s purpose

Start by describing the project itself:

• who your organization is;
• why the site is being built;
• who will use it;
• what the menu items should be;
• what sections it needs and what will go in each one.

For example: the site is needed to inform internally displaced persons about how to get legal aid.

This helps the developer understand not just the page list, but what the site is actually for. By the way, if the designer is a human (a lot of teams now use AI generation too), they’ll ask for an interview once they get the brief — because even a well-written brief rarely answers every question. Once you dig in, there can be a big gap between the original assumptions and the actual build.

2. Donor requirements

This part is worth checking before development even starts. Donors usually publish their requirements on their website or send them separately to the NGO.

In the brief, you can spell out:

• rules for using donor logos;
• the mandatory disclaimer;
• the number of language versions;
• accessibility requirements;
• any other requirements from the grant agreement or brand book.

For example, if the donor requires a logo and specific wording in the footer, plan for that from the start rather than bolting it on after launch. And yes — if something’s missing, the site can get sent back for rework. Agree on this with your contractor up front.

3. Site structure

Draft a preliminary sitemap. For example:

• Home;
• About the project;
• Team;
• News;
• Resources;
• Project results;
• Contacts.

If you need registration forms, an event calendar, a resource catalogue, search, or other features, describe those in the brief too. Try to picture everything in as much detail as possible — building some small "extra" feature can easily eat up a week. It also helps a lot if the person designing the mockup actually understands code.

On the Nashe Pidgruntya project, we had a designer who specialized in graphic design. She drew a timeline that breaks the normal rules of dynamic layout.

We pulled it off, but it took an extra week to build that unique structure. That could have been avoided by simply bringing in someone experienced in web development.

4. Accessibility

If your project requires it, spell out web accessibility requirements separately. For example:

• sufficient text contrast;
• keyboard navigation;
• correct behaviour with screen readers;
• alt text for images;
• a clear heading structure.

Don’t just write "the site must comply with WCAG." It’s better to specify exactly which level and which requirements your project needs. You can ask the donor about this, or even lean on AI for advice.

5. Content management

Think through what your NGO’s team will need to do on its own after launch. Content generally only gets hardcoded (built in with no way to edit it through the admin) when a) the developer didn’t do a good job, b) the budget is tight, or c) the project’s lifespan is very short.

For example:

• publish news;
• upload documents and reports;
• edit pages;
• update contact details;
• add photos.

If every single change means calling the developer, the site quickly becomes a hassle to use. We always record a video showing how to use the site — and as a rule, about 98% of what visitors see can be changed straight from the admin panel.

6. Technical requirements

This is where you can pin down:

• the CMS or other platform;
• responsiveness for phones and tablets;
• SSL;
• analytics setup;
• form and personal-data protection;
• any integrations you need.

You don’t have to decide on WordPress up front. But donors do tend to like that platform because it’s easy for them to understand. People still spell out "responsive" as a separate requirement, though in my view that should be a given by now — most visitors come in on a phone anyway.

SSL is the thing that keeps data on your site secure. Google penalizes sites hard for not having it these days. Ever seen that "connection is not secure" warning? People get spooked by it and just leave.

7. What you get once it’s done

This part gets underrated a lot. The brief should spell out the handover of:

• domain and hosting access;
• CMS access;
• instructions for the team.

It’s also worth deciding upfront who owns the property rights to the materials that get built.

Domain and hosting access means actual passwords in your hands — not "the developer will just handle it if anything comes up." As I’m writing this, I’m actually in the middle of rebuilding a college website. When it was first built, a security certificate wasn’t mandatory — Google didn’t penalize you for skipping it. The rules changed, and the site became inaccessible. The simple fix would have been to just add a certificate and the site would have worked again. Except... there was no domain or hosting access to be found.

This time around, during the rebuild, we made the college itself the owner — not an individual. So if the rules change again, the institution can go straight to the host on its own.

The more clearly all of this is spelled out at the start, the fewer questions come up during development — especially when the site is being built within a grant and has to fit a set budget and deadline.

If you need help writing a technical brief, we can take this part off your hands — from the section structure and sitemap to accessibility requirements and the access handover after launch.