A launch checklist for small nonprofit teams

What a small nonprofit website actually needs before launch.

A website is ready when people can find the right next step and staff know how to keep it working. Use this checklist to agree on the pages, accounts, permissions, and handoff before the build begins.

By Jalil Hay, founder of mu works · Published September 7, 2026

Use the printable checklist Nonprofit website design

I built the websites for The Accountability Foundation and The Domino Affect. This checklist reflects decisions from that work: how to explain programs, connect a public action to the correct destination, and define what the organization can manage after launch.

Use it as a working brief with your team and developer. Mark an item complete only when someone has checked it, or record why it does not apply. The scope of a simple public website will differ from a project with staff portals or connected operational systems.

01 · Visitor actions

Start with the next step, then plan the pages.

List the people who use the site: someone seeking a service, a potential volunteer, a donor, a partner, and an event attendee. Write the one next action each needs. A small organization may not serve every group online. Choose the paths that have a real owner and a working destination.

On The Accountability Foundation site, bringing the program to a community and supporting the work have separate entry points. A person should not have to interpret an organization chart to choose a route.

Ready when: Each priority audience has a clear action, a working destination, and a staff owner.

02 · Program and service pages

Explain who a program is for and how to begin.

For each program, record its name, purpose, audience, location or delivery format, availability, and next step. Include eligibility and costs when they apply and are approved. If a program is not accepting inquiries, say so. Give staff a way to retire an old date without leaving a broken page.

The Domino Affect public site organizes its work into three program areas: youth cohorts, re-entry bags, and family and community support. Those are concrete starting points for page structure, rather than one broad paragraph about impact.

Ready when: Every published program has current details, an approved owner, and a clear next step.

03 · Donation-platform ownership

Keep giving accounts in the organization’s control.

Confirm who owns the giving platform, who can recover the account, where receipts come from, and who handles donor questions. A website link and an embedded giving form have different implementation needs. Agree which one is included and test the approved path, confirmation, and return to the site.

The Domino Affect routes public giving to Givebutter. A website project should identify that boundary explicitly. Platform connections, transaction fees, account setup, and ongoing administration need a named owner; they are not automatically included in a page build.

Ready when: The organization controls its donation account and the approved giving path has been checked.

04 · Volunteer intake and follow-up

Name the person who receives a volunteer inquiry.

Ask only for what staff need for the first conversation. Separate an expression of interest from placement, screening, or a confirmed shift. Agree where submissions arrive, who responds, and how that person records the next step. If nobody can cover the inbox during leave, the process is unfinished.

Before launch, use an agreed test submission to check receipt and confirmation. Review the error state as well: a visitor should know when a form did not send and have a practical alternate contact. Do not assume that a successful button click means staff received anything.

Ready when: A volunteer test inquiry reaches the right owner and has a defined follow-up process.

05 · Accessibility

Review the actual pages and forms.

Check keyboard navigation, visible focus, meaningful headings, text contrast, image alternatives, form labels, errors, zoom, and narrow screens. Include videos and documents in the review. A person should be able to reach the important action without a mouse and understand what the form is asking for.

Use the W3C accessibility Easy Checks as a starting point. They are a preliminary review, not a complete accessibility evaluation. Agree the project’s testing target and record unresolved issues in third-party donation tools or other content, with a responsible owner.

Ready when: Keyboard, focus, forms, contrast, media, and zoom checks are documented with open issues assigned.

06 · Privacy and data collection

Collect only what the next step needs.

Inventory forms, analytics, embedded media, donation tools, and email subscriptions. For each, identify the information collected, where it goes, who can access it, and how long it is kept. Keep sensitive participant stories and case information out of a general website inquiry.

Write privacy information that describes the tools and behavior actually in use. Decide how consent choices work before adding optional tracking or embeds. The organization should approve the collection and retention decisions, including any requirements specific to its services and audience.

Ready when: Forms, tracking, embeds, access, retention, and privacy copy have been reviewed together.

07 · Staff editing permissions

Test a routine update with the intended editor.

List what staff need to change: program text, event dates, updates, gallery images, or team details. Define who may edit, who may publish, and who manages accounts. Test with a staff account instead of assuming that the developer’s access represents the handoff.

For The Domino Affect, the project included an admin portal, content tools, and recorded training. A useful acceptance check is a routine content update completed by the intended editor. Record the steps and any help needed before making claims about time saved.

Ready when: The intended editor can complete an agreed update and understands publishing and account recovery.

08 · Content ownership

Make account and asset ownership explicit.

Record who controls the domain, code, hosting, content, and connected accounts. Keep renewal and recovery contacts current. Make sure the organization can obtain an export or handoff when needed, and agree which ongoing tasks belong to the care provider.

Confirm permission for photographs, logos, quotes, and participant stories before publishing. Identify who approves corrections and removal requests. Keep the approved originals and the source of important claims together so the next staff member does not have to reconstruct them.

Ready when: Domain, code, content, assets, renewals, and access responsibilities are documented.

09 · Analytics

Measure completed actions with clear limits.

Choose a small set of events that matches the website’s purpose, such as a successfully submitted inquiry or a click through to a giving platform. Keep names, email addresses, message text, and participant details out of analytics events. Check what happens when a visitor declines optional analytics.

Use Search Console for search visibility and analytics for activity after landing. A click on a donation link is not a completed donation. Keep those measures separate and reconcile completed giving in the donation platform. An inquiry is qualified only after someone reviews its fit.

Ready when: Agreed events work without sending form answers, and clicks are distinguished from completed outcomes.

10 · Launch and post-launch responsibilities

Finish with a named owner for every open item.

Before changing the domain, review the agreed pages, redirects, links, forms, mobile layout, account access, and search settings. Identify who approves launch and who can restore the prior version. Record what remains open and whether it prevents the public site from working.

After launch, check the live domain and the important visitor paths again. Give the team a short handoff with editing instructions, support contact, renewals, routine care, and the next review date. Launch is complete when the public paths work and the responsibilities are understood.

Ready when: Launch approval, live checks, handoff, support, renewals, and the next review have named owners.

References for the review

W3C: Easy Checks for a first accessibility review covers the starting checks referenced above. Google: using Search Console and analytics together explains their different measurement roles.

The project examples can be inspected on The Accountability Foundation website and The Domino Affect website. Public pages were reviewed September 7, 2026.

For scope and pricing, see nonprofit website design in Southern Indiana and Louisville.