When the words “please respond to the attached RFP” show up in an email, we still wince a little. Not because a formal process is wrong. Because of what most software RFPs ask for, and what they leave out.
If your company requires an RFP, this article is for you. It explains why the traditional version selects badly, what to put in one instead, how to check references, and ends with a simple template you can fill in this afternoon.
What an RFP is supposed to do
A request for proposal is a formal document a company sends to vendors so they can bid on a project. In procurement-heavy organizations it is mandatory, and if that is your situation, we understand. You are doing your job.
The problem is that a typical software RFP reads like a purchase order for a machine. A long list of features, a request for a fixed price and a delivery date, and a scoring sheet. What comes back is a stack of documents. The one with the best formatting or the lowest number wins. For a custom software project, that is a coin flip dressed up as diligence.
Three reasons traditional RFPs pick the wrong partner
They keep the two sides from talking
Software work runs on trust, and trust comes from conversations, not documents. A traditional RFP often forbids contact with bidders during the process, which means you choose a team you have never spoken to for work that will take months and depend on daily communication. The process is designed to prevent the one thing that would tell you the most.
They ask for a price before anyone understands the problem
Most RFPs arrive with feature lists but very little about the business. Who the users are, what is broken today, what success would look like a year from now. Without that, a vendor either guesses at a number, pads it heavily, or quotes low and makes it up in change orders. None of those outcomes are good for you. Asking a firm to price fuzzy requirements is asking them to make something up, and the most confident fabrication wins.
They pretend firms are interchangeable
You are not buying widgets. Firms differ in who does the work, where they are, how they handle money, how they handle risk, and what they will refuse to do. We are a Texas team with no offshore and no outsourcing, we work to a fixed budget with controlled scope, and we start every new build with a planning step instead of a guess. Other firms make different choices. A scoring grid built around a feature list cannot see any of that, and it is exactly what decides whether the project works.
What an effective RFP asks instead
The fix is to change what the document is for. Use it to describe your business and your problem clearly, and to learn about the firm and its people. Do not use it to collect a price for a scope that does not exist yet.
Ask about the company. How long it has been around, who owns it, whether the owners still run it, how big the team is and how long people have stayed. Ask about financial health. Most firms will not share revenue or profitability, and the ones that do are telling you something about how they operate.
Ask about the people. Who exactly would work on your project, and where are they? Is the team that shows up for the sales conversation the team that does the work? What do they invest in for professional development?
Ask about past projects, specifically. Past performance is the best predictor of future success. Ask for two or three relevant projects with the size, duration, and business result, not the technology list. Then ask the questions most RFPs skip: what was a project that failed, why did it fail, what did the firm do about it, and did the client keep working with them afterward? A firm that cannot name a failure has either not done enough work or is not being straight with you.
Ask how they would approach your problem. Not a price. An approach. What do they see as the risks? What assumptions are they making? How do they handle money, and what happens when the project learns something that changes the plan? How do they communicate, report, and release? What happens after launch: support, response times, hosting?
Say how you will decide. Tell bidders what matters to you and roughly how you will weigh it. It makes the responses better and it keeps your own committee honest.
Always check references
Do not skip this step, whatever the RFP process says. References are firsthand insight into how a team actually behaves over months. Questions worth asking:
- Who did you talk to day to day? Was it the people doing the work, or an account manager in between?
- How often did you get a new release you could try? Weekly is possible once a project is rolling. Monthly is the longest you should tolerate.
- How was your feedback handled? Was it written down and then acted on?
- Could you steer the project and change your mind about features as you learned?
- Did you get regular status that showed work done, work remaining, and budget used?
- Were you ever surprised?
- How often did you hear “we can’t do that because you didn’t tell us earlier”?
- Did the project come in on budget? If not, what happened, and did you see it coming?
- Were you encouraged to build less and ship sooner?
The last one matters more than it sounds. Clients usually want to build too much. A team that pushes back on scope is a team that has your budget in mind.
The three questions that decide it
When the documents are in and the calls are done, ask yourself three things about each firm:
- Do you communicate well with their people?
- Do you believe they understand your business and your problem?
- Do they ask good, smart questions?
If the answer is yes to all three, you have a partner. If it is no to any of them, the price does not matter.
What happens next with us
If you send us an RFP built this way, we will respond with a conversation before a document. A 30-minute intro call, then a Deep Dive, and if it makes sense a fixed-fee VDP Sprint for something new or a System Evaluation for something that exists. That step is what produces a real scope and a real number, on a contract model we recommend after we understand the work. The typical budgets by type of project are on our pricing page if you need a range for the RFP itself. If you want to see the difference between a strong and a weak response, read a sample RFP response, walked through.
A simple RFP template
Copy the headings below and answer the prompt under each in a few sentences. A good RFP fits on three or four pages.
1. Company background Who you are, what you do, how big you are, and who owns the company. One paragraph. Include anything a stranger would need to understand your business.
2. The business problem What is broken or missing today, what it costs you, and what you have tried. Describe the problem, not the software you imagine solving it.
3. Who the users are Every group that will touch the system: staff roles, customers, partners, leadership. How many of each and what each needs to get done.
4. What success looks like Twelve months after launch, what is measurably different? Name the two or three numbers you would use to judge the project.
5. Constraints and integrations Systems it must connect to, data it must use, security or compliance obligations, and anything that cannot change.
6. Budget range and timeline expectations The range you are prepared to invest and any real deadline. If there is a date, say what drives it.
7. How you will evaluate The factors that matter to you and roughly how you will weigh them.
8. What you want back The company, people, past-project, and approach questions above. Ask for an approach and a planning proposal, not a fixed price for the full build.
9. Timeline for the process When questions are due, when responses are due, when calls will happen, and when you will decide.
What a good response looks like
A strong response answers every question you asked in plain language and adds the ones you should have asked. It names the actual people who would do the work. It describes an approach and the risks it sees, including risks in your own request. It explains how money is handled and what happens when the project learns something new. It proposes a first step you can afford and evaluate, usually a fixed-fee planning engagement, rather than a full-build price built on assumptions. And it comes with a request for a conversation.
A weak response is a template with your company name pasted in, a price that arrived suspiciously fast, and no questions at all.
If you are writing an RFP now, start with an intro call. We will tell you whether we are a fit before you spend a week on the document.