How Writing Better RFPs Builds Stronger Relationships and Better Outcomes
by Zach Davis
The best RFPs are those that spark real conversations and set the stage for lasting partnerships. I’ve been reading requests-for-proposals from mission-driven organizations for years now, and a fundamental mistake I see repeated time and again is thinking of the RFP only as a functional checklist. Great RFPs go beyond bullet points, making the crucial first step towards a discursive, consultative relationship with a long-term partner.
Great Partners are eager to help—you just need to invite them in. Nonprofits deserve creative, committed web partners. The first step is a better RFP.
The distinction between a partner and a vendor is an important one. Partners are good at listening. A partner will engage the problem you’re trying to solve and understand why you need to solve that problem and how it fits into larger organizational goals. A true partner is skilled, and can therefore execute on tactical goals, but they’re also experienced, and use that experience to bring strategic thinking to your project. You’ll know when you’re working with a valuable partner because sometimes that partner will push back on what you’re asking for. Other times they’ll redirect the request or amplify it because they’re bringing new ideas to the project, suggesting options you may not have known were possible.
A vendor, on the other hand, does what they’re told. You tell them what you want built and they do it. A vendor is trying to check a box, to make sure that they’ve met the requirements adequately (often at the least amount of expense to themselves). Vendors don’t push back. They’re order takers. In some cases a vendor might meet your needs, but when it comes to creative and engineering work, a partner is almost always preferable.
I’d argue that the primary point of a RFP should be to 1) separate the partners from the vendors, 2) identify the strongest partner for your organization, and 3) begin laying the groundwork for an innovative, trust-based collaboration that drives mission and impact.
In two decades of building web products, I've come to believe that trust is in fact the special ingredient that determines whether a project meets or exceeds client expectations. When our clients trust our skills, our judgement, our experience, and our commitment to their mission, we have more impactful outcomes. Trust goes both ways. We need to trust our clients to fully and transparently share their challenges, processes, domain knowledge, and mission with us so that we can be effective collaborators. Client trust is not given lightly, nor should it be. It's earned through repeated, successful engagements, and by always showing up when clients need us.
Transformational partnerships are built on trust, and RFPs should be written so as to draw out responses that reveal how potential partners think, collaborate, and navigate challenges. This requires moving beyond standard checkbox questions about technical capabilities and asking instead about , philosophy, and past experiences handling complexity. The best RFP questions invite respondents to share their actual thinking rather than simply demonstrating they can follow instructions.
Unfortunately, many RFPs inadvertently filter for vendors rather than partners. They focus heavily on detailed technical specifications, rigid timelines, and lowest-cost bidding—all signals that the organization wants someone to execute a predetermined plan rather than collaborate on solving a problem. These RFPs attract order-takers who excel at compliance but may lack the strategic thinking and creative problem-solving that nonprofits actually need.
To identify true partners, your RFP should create space for respondents to demonstrate curiosity, ask clarifying questions, and propose alternative approaches. As you write the RFP, look for opportunities to include partnership-oriented language, which could be language that makes it clear that you’re ok with being pushed and challenged, or language that acknowledges the iterative process that is common with creative projects.
Now that we’re thinking about the RFP as a tool for finding a partner, here are some ways you put these principles into practice:
Introduce yourself to the proposers so they can better serve you.
You’re seeking out a skilled partner because you have a non-trivial problem that you want them to solve. The first step to getting high quality proposals is carefully communicating your organization and the problem you want solved. Take a few paragraphs to describe the structure of your organization, its mission, and how it positions itself in relation to other similar organizations.
What makes your organization unique?
What are its key strengths and differentiators?
How does your audience see you?
The answers to these questions are foundational, and any solution to your problem will need to take them as a starting point. Taking the time to contextualize your organization tells prospective partners that you’re already thinking carefully about who you are and what you do, and it creates space for proposers to bring solutions that are specifically tailored to you. Keep in mind, you don’t need to say too much here, especially if you’re already doing a good job communicating your mission and position. It’s OK to expect a partner to do their research on your organization.
Focus on problems and benefits rather than solutions.
We can conceptually reduce most projects to problems, solutions, and benefits:
The project is motivated by one or more problems
The partner creates a solution to those problems
The client receives benefits as a result of the solution
Your RFP should focus on the problems and the benefits, and the proposals you receive should describe solutions and make an argument for how those solutions will bring you the required benefits.
Many RFPs fail to define the problems and the benefits, and instead try to describe the solution. Describing the solution can take a lot of forms, but it generally shows up as a list of features or a catalog of technologies that need to be present in the solution. RFPs that take this approach are missing an opportunity by failing to make space for the partner to describe a creative solution to the organization’s specific problem.
Define the problem carefully. If the RFP is for a website redesign, explain why the redesign is happening now. There are lots of reasons why a redesign might be necessary. Perhaps your organization’s mission has shifted and the current site no longer serves your needs? Or maybe the design is dated and clunky, and your users have expressed frustration. Maybe you’ve decided to produce new kinds of content that don’t fit into the current site, or perhaps there are more transactional actions that users need to take on the site that didn’t exist when it was first built. There are countless reasons to redesign a site. If you can articulate what those reasons are, you’re much more likely to receive responses that offer creative ideas that speak to your specific needs.
As you define the problem, define the benefits you expect to receive from the project. If the redesign comes together brilliantly, what would the outcome be? Do you want to get more traffic? More conversions? More sales? More contacts? Fewer unqualified contacts? More publicity? More thought leadership? Again, there are many possible benefits from a project. Taking the time to define them up front will yield better proposals while also giving you a way to measure the project’s success and share that success internally and externally.
Just be open about dates and budgets.
At Cast Iron, most of our projects fall somewhere between $10,000 and $500,000. That’s a huge range! When we get an RFP that doesn’t include a budget, we have to guess where the project should land in that range. While it’s pretty easy to tell the difference between a 30k website and a 300k website in terms of scope, it’s a lot trickier when we’re talking about 50k vs. 75k. The same fundamental site could be built at both price points, but the less expensive version would have fewer affordances, more manual processes, less interactivity, and less content and presentational variety. Both versions could be a great product that met the client’s needs. When the RFP fails to specify the budget or provide a range, proposers will just make a best guess, which may or may not be accurate. If you’re a non-profit, that guess will be based off your public financial statements and projects we’ve done for similar organizations, which may or may not correspond to what you’ve actually budgeted for the project.
Hiding your budget doesn’t give you leverage over proposers. In fact, it opens up space for your proposers to exclude details about their solution so they can later fit it to the actual budget. Let’s say you conceal your budget, and you receive a proposal that makes big promises at a low price. It’s likely that in the actual implementation, the vendor will use quick solutions to meet the ostensible promise.
Any feature has more and less complicated ways to implement. For example, if you want video on your site, one approach might be to just embed a YouTube video, which comes with advertisements and generally poor user experience. It’s cheap, fast, easy, and checks a functional box. A more robust approach, however, might involve letting content editors upload a video in the CMS, have a service transcode it into various web delivery formats, automatically generate a transcript for accessibility purposes, upload it to a third party streaming media service, and render it on the frontend of the site. By sharing the budget, you shift the burden onto the proposers: be specific about what functionality I can expect at this specific price point.
If scope is unknown during the proposal phase of a project, the timeline is likely also unknown. Inevitably, your team will need to devote resources to the project. You’ll need to review deliverables, offer feedback, help shape strategy, perhaps write content, and more. How the project unfolds will depend on your partner’s resources and on your resources, so defining a clear timeline up front can be tricky and in some cases impossible.
Instead, just share your drop-dead dates with the vendor. If the site has to launch on a certain date, share that and let the vendor work backward from it. Or, if you have a rough sense of the timeline you’d like to see, include it as an ideal timeline, but don’t hold on to it too tightly during the proposal phase.
In fact, a final budget and timeline should be a deliverable that comes out of the discovery phase of the project. These are deliverables that you should be cooperatively creating with your partner. Your partner will need to ask you questions about why you need each feature, how you imagine using it, how it integrates with other features, and more. The true scope of the project will come out of those conversations, and will lead into an accurate budget.
I’m not trying to suggest that the cost of a project is unknowable before it begins. Experienced partners should be quite good at looking at your proposal and guessing how much it will cost based on other similar projects they’ve done. Strong partners will have years of data about how much time was spent on each project and they’ll be good at analyzing that data to get better at estimating new projects. Ask your proposers to give you a range of possible costs. If you’re unwilling to share your budget—and I’d argue that an RFP should always share the budget so that agencies can write appropriate proposals instead of trying to guess or infer the budget—ask the respondent to describe what the solution would look like at different price points. Is there a small, medium, and large approach to the project? What would each one look like? These questions will give you more meaningful insight about the partner’s approach and solution than an ill-informed line item estimate will.
Ask partners to speak to your specific challenges.
If your goal is to find a good partner, you need to first identify what qualities your ideal partner possesses. For a web project, you probably need a team that can demonstrate skill in user experience design, visual design, web development, information architecture, and content strategy, as well as the ability to provide ongoing support and maintenance. Just as important, you should be looking for a partner who can get up to speed on your specific organizational goals quickly.
The best part of working at an agency is that we get to work with clients in many different areas—publishers, museums, non-profits, foundations, enterprise clients, etc.—and over time our team becomes skilled at quickly learning what clients need (through listening and engaged questioning) and proposing tailored solutions.
Once you know what you’re looking for in a partner, start thinking about what you can ask for in the RFP that will position the partner to demonstrate those skills.
Some RFPs choose the path of spec work, which involves asking the proposer to do some amount of speculative work to show that they can do the work. Agencies, especially small agencies with tight margins, will resist doing this, which I think is generally the right response. Spec work raises the cost of responding to RFPs, which means you’re more likely to get responses from vendors who cast a wide net and are equipped to do fast, cheap work. Spec work tends to be surface level because there’s not meaningful engagement between the vendor and the client.
Instead of asking for spec work, ask for examples, preferably from other projects. Asking for previous work doesn’t require the proposer to create something new, and that work is likely higher quality because it came out of an informed process. You might, for example, ask a proposer for examples of how they approach UX design, which would show you the level of detail that they think is appropriate for wireframes. Or you might ask for an example of production design, which will demonstrate whether the partner thinks about design as composable, component based systems. You might ask them to share a diagram of the tech stack for a similar project. Asking for these kinds of artifacts from other projects will likely give you a better sense of how the proposer approaches projects than spec design will.
I’m a big fan of RFPs that pose targeted questions asking the partner how they would solve specific, mission critical problems. Pick these questions with some restraint. Asking a partner to explain how they’d solve ten different problems is asking a lot. Giving them a couple important problems and asking them to explain their approach is a reasonable ask.
This strategy forces each respondent to answer the same questions, which helps you compare and rank responses. You’ll also find that questions about your specific challenges are questions that require real engagement and thought from the partner. They won’t be able to use stock language to answer them, and when you review their response you’ll be able to collect important information about the vendor. As you read the response, ask yourself the following questions:
Is the respondent able to clearly articulate and communicate their solution? Or is the response unclear, full of jargon, or perhaps written by AI?
Is the response expansive and creative, or are they constrained by their particular solution? Many vendors have one way that they approach all projects, and they shape the project to fit the solution. You’ll probably have better luck with a partner that has lots of strategies for solving problems, and is trying to find the right one for your specific problem.
Does the respondent ask questions and leave open possibilities? Most good partners will offer solutions, but understand that they need to learn more before they can hold those solutions too tightly, and they’ll use the proposal as an opportunity to start a consultative dialogue with you.
It’s OK to keep things fuzzy at this stage of a project.
Assuming what you want is a partner, you should go into the RFP process knowing that you probably don’t know exactly what you’re going to be buying.
Sure, you generally know that you want a website or a web application, but if you’re doing this right, you don’t know what that solution will look like until you talk to the partner. Maybe you need to rethink your communication strategy. Maybe the upstream CRM that the site integrates with can’t do what you want to do and we’re going to have to migrate data to a new CRM. Or maybe it’s the opposite—maybe you think you need a new CRM but our team can build some integration and automation with the current CRM that solves your problem. Maybe the content you think you’re going to migrate doesn’t actually meet your users’ needs and it has to be rewritten. It’s probably the case that nobody knows the true scope of the project until some discovery, discussion, and planning work has taken place.
Doing that work correctly is involved, and shouldn’t be considered part of writing a proposal. The proposal serves to separate the partners from the vendors, not to nail down exactly how this project will solve your problem.
Use small discovery engagements to minimize risk.
Every serious project requires discovery and planning, which should be considered a phase in the project itself. Even the best RFPs are not enough to just start work. Once you’ve selected a partner, you’ll need to discuss the project and explore different approaches before you can fully understand the scope and cost. After all, that’s why you hired a partner in the first place, because you wanted someone who could bring exciting ideas to the table!
Discovery gives your partner a chance to explore those ideas and their ramifications to the scope, budget, and timeline.
Breaking the discovery and planning phase into a separate scope of work (SOW) is a terrific way to get a feel for your partner before going all in, and the deliverables from this phase—which can include a timeline, a detailed budget, a functional specification, personas, sitemaps, and even low-fidelity user experience design—can all be used as inputs for the larger project SOW, which will put you on a better contractual footing with the partner.
The RFP process doesn't have to be a necessary evil that both sides endure. When approached thoughtfully, it becomes the foundation for relationships that can transform organizational capacity and impact. By focusing on partnership from the very first interaction, you're not just finding someone to build a website—you're finding an ally who will help you solve problems you didn't even know you had.
The extra time invested in crafting a partnership-focused RFP pays dividends throughout the project and often extends into years of productive collaboration. Spend a little time on the RFP up front and who knows, you might just find a partner who's as invested in your success as you are.
Ready to kick off a project with a trusted partner? The Cast Iron team specializes in creating the types of digital experiences that deliver mission-critical results. Whether you’re just starting to conceptualize your RFP, or are looking for responses, reach out to our team to start the conversation.