Most website regret is avoidable. It usually comes from skipping these conversations before the project starts.
A website rebuild is one of the most significant operational investments a mission-driven organization makes. Unlike a one-time event or a campaign, the website will carry institutional weight for years – shaping how donors evaluate credibility, how funders assess programs, how board members present the organization, and how community members decide whether to engage.
The organizations that regret a website investment almost never regret the decision to rebuild. They regret how the decision was made: what was not clarified before the project started, what was assumed rather than confirmed, and what the partner did not ask before the first design mockup appeared.
These questions are not a checklist to complete. They are a conversation to have: with your team, with your leadership, and with any web partner you are evaluating – before work begins.
Before evaluating any web partner, these questions should be answered internally. A partner who begins work before your organization has answered them will be building on an unstable foundation.
Who does our website actually need to serve – and what does each of those audiences need from it?
Most mission-driven organizations serve multiple audiences simultaneously: donors, funders, program participants, board members, community members, referral partners. Each audience needs something different from the site. If your team cannot name your primary audiences and describe what each one needs before the rebuild begins, the project will drift toward serving whoever is loudest in the room rather than whoever matters most.
What is our website currently doing well – and what is it failing to do?
A rebuild should address specific failures, not just produce a more modern-looking site. If your team cannot name what is specifically not working, and why the rebuild may improve the aesthetics while leaving the real problems intact.
Who has the authority to make final decisions about this project?
Website rebuilds that involve committee-based approvals, multiple stakeholders with veto power, or unclear decision-making authority almost always run over time and over budget. Before the project begins, your organization should designate a single point of contact with clear authority to approve direction, content, and design decisions. This does not mean bypassing leadership, it means agreeing in advance on a process that keeps the project moving.
What content do we have and what content do we need to create?
Content is almost always the bottleneck in a website rebuild. Organizations that arrive at the build phase without organized, current, approved content extend their timelines significantly and sometimes end up with a beautifully structured site populated with outdated or placeholder content. Honest assessment of content readiness before the project begins prevents this.
What happens to the website after it launches?
A website without an ongoing care plan will begin to decay within six to twelve months. Before committing to a rebuild, your organization should have a clear answer to who is responsible for updating content, who will manage technical maintenance, and how ongoing care will be funded. If the answer is unclear, the Sunlight Monthly Retainer is worth discussing before the project closes.
What is our realistic budget – and what are we prepared to invest in ongoing care?
The rebuild investment and the ongoing care investment are separate decisions. An organization that invests $20,000 in a rebuild and then allocates nothing for ongoing care will find itself making the same investment again in three to four years. Understanding both numbers before the project begins produces better decisions and better outcomes.
These questions separate partners who build websites from partners who build durable systems for organizations like yours.
How do you begin a project – what happens before design starts?
A partner who begins with visual concepts before understanding your audiences, programs, and organizational priorities is optimizing for speed rather than outcome. The Brand phase, Discover, Define, Design, should happen before any structural or visual decisions are made. If a partner cannot clearly describe what they learn about your organization before they start building, that is a risk signal.
Have you built websites for organizations similar to ours – and can we speak to a client reference?
Sector experience is not interchangeable with general web experience. A partner who primarily builds e-commerce or small business websites will not understand the governance dynamics, content complexity, or audience diversity of a museum, nonprofit, or cultural institution. Ask to see relevant examples and ask for a reference from a client who went through a similar decision-making process to yours.
How do you handle competing opinions inside an organization?
Mission-driven organizations rarely make website decisions through a single point of authority. Board members, executive directors, program staff, and communications teams often have different – and sometimes conflicting – opinions about what the website should say and how it should look. A partner who has not navigated this dynamic before will be caught off guard by it. Ask specifically how they have handled it in previous projects.
What does the project include – and what does it not include?
Scope misunderstandings are the most common source of project conflict and cost overruns. Before signing any agreement, your organization should have a clear, written understanding of what is included in the project – pages, rounds of revisions, integrations, copywriting, photography, training – and what falls outside the scope. Ask specifically about what triggers additional billing.
What happens at launch – and what happens after?
A partner who considers the project complete at launch is a vendor, not a partner. Ask what post-launch support is included, how long it lasts, and what ongoing care looks like after it ends. Ask specifically whether your team will be trained to manage and update the site confidently – or whether you will be dependent on the original builder for routine changes.
How do you approach AI search visibility and accessibility?
Both should be addressed during the build, not added afterward. AI search visibility affects whether your organization appears when donors and funders use AI tools to research organizations like yours. Accessibility compliance affects whether your site can be used by all members of your community and whether your organization faces legal exposure. A partner who treats these as optional add-ons is making decisions that will cost you more to fix later.
What is your process for content review and accuracy?
For organizations that publish program descriptions, outcome claims, leadership credentials, or service information, content accuracy is a credibility issue. Ask how the partner handles content review before publishing and whether they flag content that may be vague, unsubstantiated, or inconsistent with your organization’s actual work.
Is the scope of work clearly defined in writing?
A verbal understanding of scope is not a scope. Before signing any agreement, the scope of work should specify exactly what is included, how many revision rounds are allowed, what your organization is responsible for providing and when, and what constitutes a scope change that triggers additional billing.
What are the payment terms and what triggers each payment?
Most website rebuilds are structured with milestone-based payments: a deposit at signing, a payment at a defined project milestone, and a final payment at launch. Understand what each payment is contingent on and what happens if a milestone is delayed by either party.
Who owns the website and its content after the project ends?
Your organization should own the website, the domain, the hosting account, and all content produced during the project. Confirm this explicitly before signing. Some agreements include licensing arrangements for design elements or platform access that affect your ability to move the site to a different partner later.
What are the terms for ending the project early if needed?
Organizational circumstances change: leadership transitions, funding shifts, program pivots. Before signing, understand what happens to work completed and payments made if the project needs to be paused or ended before completion.
The organizations that navigate website rebuilds most successfully are the ones that spend more time on these questions before the project begins than on evaluating design portfolios or comparing price quotes.
Design quality matters. Price matters. But neither determines whether the project will serve your organization for years or require rebuilding in three.
What determines that is clarity: about what your organization actually needs, about what a partner actually builds, and about what both parties are committing to before the first step is taken.
If your organization is not yet ready to answer these questions confidently, the Executive Website Clarity Assessment is designed for exactly that moment. It provides a structured, objective evaluation of your current site and your organizational readiness – giving leadership the information needed to make a confident website decision before committing budget or board approval.
Before you contact any web partner. The organizations that have the most productive first conversations with web partners are the ones that have already answered the internal questions – who the site needs to serve, what is currently not working, and who has authority to make decisions. Coming to that first conversation with clarity rather than uncertainty produces better outcomes and better partner relationships.
That is a signal that the organization is not yet ready to begin a rebuild – and that is useful information before you commit budget or board approval. The Executive Website Clarity Assessment is designed for exactly this situation. It provides a structured process for developing the answers your organization needs before any build begins.
Two to three is sufficient for most organizations. Evaluating more produces decision fatigue without meaningfully improving the quality of the final choice. Use the partner evaluation questions in this guide consistently across every partner you consider – how they answer those questions will tell you more than their portfolios will.
Choosing a partner before clearly defining what the website needs to accomplish and who it needs to serve. The second most common mistake is beginning the project without a designated internal point of contact who has clear decision-making authority. Both are avoidable with the questions in this guide.
No, these questions should come before proposals, not after. A proposal is only as useful as the clarity that informed it. A partner who sends a proposal before understanding your audiences, organizational priorities, and content readiness is estimating, not scoping. Get aligned internally first, then invite proposals from partners who have answered the partner evaluation questions in this guide to your satisfaction.
A strong proposal describes the process before the deliverables – how the project begins, what your team is responsible for providing and when, what revision rounds are included, and what triggers additional billing. If a proposal jumps directly to deliverables and price without describing process and scope boundaries, ask for clarification before signing.
Resolve it before the project begins, not during it. Internal disagreements that are unresolved at the start of a project surface mid-build, after budget is committed and timelines are set, and are the most common cause of projects running over time and over budget.
The Executive Website Clarity Assessment provides an objective third-party picture of what the site actually needs rather than what each stakeholder believes it needs.
Frame it as institutional infrastructure rather than a marketing expense. Document the specific ways the current site creates friction, present a clear scope and investment range, and define a measurable outcome. The Executive Website Clarity Assessment report provides objective third-party documentation that makes the board conversation significantly easier than presenting a proposal without supporting evidence.
A refresh updates surface elements: photos, text, colors – without addressing underlying structure. A rebuild restructures the site from the foundation. When staff hesitate to update the site, navigation no longer reflects current programs, the platform is outdated and creating security risk, or the site no longer reflects the organization as it exists today, a rebuild is warranted. The Executive Website Clarity Assessment clarifies which applies before you commit resources in either direction.
Ask to see two to three examples of work done for organizations similar to yours in sector and complexity – not just general web experience. Ask specifically how they handled content complexity, committee-based decision making, and stakeholder review processes.
Ask for a client reference you can speak to directly. Sector experience is not interchangeable with general web experience, and the difference becomes apparent during the project rather than before it.
This is why a clearly written scope of work matters before signing any agreement. It should specify exactly what is included, what triggers additional billing, and what constitutes a scope change. Organizations that sign agreements without this clarity are exposed to cost overruns that could have been avoided. Before signing, ask specifically what happens if your organization requests changes mid-project and what the process is for managing scope additions.
Most mission-driven organization website rebuilds take 10 to 16 weeks from the Discover step through launch, depending on scope and the speed of internal content review and approvals. Organizations with a single designated point of contact and organized content ready at the start of the build phase consistently launch on the faster end of that range. Setting realistic internal expectations about timeline and content readiness before the project begins is one of the most effective ways to protect both.
Questions first? Start a conversation
