Insights · 10 min read
The RFP questions that separate a real software development partner from a polished sales pitch. What to ask about the team, process, budget, and what happens when a project goes wrong.
By GGP Editorial
A request for proposal does two jobs. It tells vendors what you want built, and it filters out the ones who should not be building it. Most companies get the first job right and skip the second.
The questions in an RFP are not there to fill a spreadsheet. They are how you find out whether a vendor can actually deliver, or whether they are simply good at answering questions. A polished reply tells you the sales team is sharp. It tells you nothing about the engineers who will do the work.
Here are the questions that matter, and why each one exposes something a vendor would rather keep quiet.
The first thing to find out is who will be writing your code. This is the question vendors deflect most often, because the honest answer is usually less impressive than the pitch.
Ask for the names and seniority levels of the engineers who would work on the project, and whether that roster is fixed. A vendor that cannot name the people has not actually allocated them. What you get instead is whoever is free when the contract is signed.
Ask how many projects each engineer carries at once. A senior engineer spread across four accounts is a part-time engineer on yours. Some shops will tell you "we always have capacity", which is another way of saying you will not have a named team.
Ask who the day-to-day contact is, and whether that changes. You want one person who owns your account, reads your messages, and answers the same questions you asked last week. If the contact rotates, you re-explain your product every month and nothing ships faster for it.
Ask about turnover. The honest number is never zero. What you are listening for is whether the vendor can describe how they hand a project from one engineer to another without losing three weeks. If they have no answer, a single resignation becomes a project reset.
This section matters most, and it is the one most buyers skip because it feels rude. It is not rude. It is the difference between a team and a queue.
Delivery questions separate a vendor with a process from one with a sales deck.
Ask how they estimate a feature before it is built. You want to hear a method: user stories broken down, a team sizing each one, a buffer for the parts nobody understands yet. If the answer is "we will scope it when we get there", the budget is a guess. If you want to pressure-test estimates against reality, we have written about how to estimate a custom software project.
Ask how they handle a requirement that changes mid-sprint. Software changes. The question is whether change is a normal part of the process or a surprise that resets the schedule. Listen for a change-management answer that does not begin and end with "that will cost extra".
Ask what a week of delivery looks like. What do you get on Friday: a demo, a written status note, a build to test, or silence? A vendor that can describe their weekly rhythm in one sentence has run projects before. One that cannot has not.
Ask how they test. Not "do you test" — everyone says yes. Ask who tests, when in the cycle, and how bugs get back to you. If testing only happens at the end, you are the tester.
Ask how they report progress. A good answer names the artifact: a status note, a demo, a list of what shipped and what is blocked. You should know exactly what you will see each week before you sign.
Money questions are where vendors get vague on purpose, so this is where you should be specific.
Ask what is and is not included in the estimate. Scope documents hide assumptions. Does the price cover deployment, hosting setup, documentation, the first round of fixes, or none of it? A vendor that cannot list what is excluded has not thought about it, which means you will pay for the thinking later. It also helps to know where the money actually goes in a custom build before you compare two quotes line by line.
Ask how they handle a fixed-price project when the scope turns out to be wrong. Both of you will misjudge something. The question is whether the vendor's answer is "we renegotiate" or "we work it out together". The second one costs you less.
Ask about time-and-materials versus fixed price, and ask them to recommend one for your project. A vendor that always says "fixed price" is selling certainty they cannot deliver. A vendor that always says "time and materials" may not want the risk. The right answer explains the trade-off for your specific project. We have written about how to actually pick between the two if you want to go in prepared.
Ask what happens after launch. Software does not end at go-live. Ask what support looks like, what it costs, how fast they fix a production bug, and whether the source code and accounts are handed to you in full. You own the code, not a subscription to your own product.
Every project hits a problem. The difference between vendors is how they behave when it does.
Ask them to describe a project that went badly and what they did about it. This is the best question in any RFP. A vendor with no bad stories is either new or lying. A vendor who can describe the problem and the recovery, without blaming the client, is the one you want.
Ask what happens when a deadline slips. Listen for ownership. "We tell you early, we re-plan, we tell you what we can still hit" is the right shape. "We will add resources" is a red flag, because throwing more people at a late project usually makes it later.
Ask about their process when a bug reaches production. You want a specific answer: how fast they respond, how they decide severity, who you can reach. If the answer is a phone number with no process behind it, that is the process.
Ask who owns the code and the accounts. The answer should be you. The domain, the repository, the cloud account, the intellectual property. If a vendor hesitates on any of these, that hesitation is expensive to fix later.
If your RFP has room for twenty questions, these are the ten I would keep. They produce real information instead of marketing copy.
| # | Question | What the answer reveals |
|---|---|---|
| 1 | Who exactly will work on the project, and is the roster fixed? | Whether a real team is allocated or you get whoever is free |
| 2 | How many projects does each engineer run at once? | Whether your engineers are actually full-time on you |
| 3 | Who is my day-to-day contact, and does it change? | Whether you get one accountable person or a rotating queue |
| 4 | What do I receive each week — a demo, a note, a build? | Whether the vendor has a delivery rhythm |
| 5 | What is not included in this estimate? | Where the hidden costs are |
| 6 | Describe a project that went wrong and how you handled it | Whether the vendor takes ownership or blames |
| 7 | What happens when a deadline slips? | How they behave under pressure |
| 8 | Who owns the code, repo, and cloud accounts? | Whether you control your own product |
| 9 | How do you handle a requirement change mid-build? | Whether change is normal or a surprise |
| 10 | What does support look like after launch, and what does it cost? | Whether the price is honest end to end |
Ten questions is enough. More than that and you are measuring how well someone fills in a form, not how well they build software.
The RFP is one step in a longer process, and it works best when the steps before and after are solid. Before you send questions, you should know what you are asking for. A vendor can only answer well if your requirements are clear. We have written a guide to the requirements document and one on writing the RFP itself. Get those two right before you start interviewing vendors.
The RFP is also not the only way to pick a partner. Some buyers skip the formal document and move straight to a shortlist, which works when you already know what good looks like. If you are weighing offshore options, this guide to choosing an offshore partner covers the same ground from a different angle.
One warning. Do not send the same long list to twenty vendors and pick the prettiest reply. The point of these questions is to have a conversation, not to collect documents. The best vendors will answer most of them over a call, and their willingness to do that is itself an answer.
We are a software firm with 40-plus engineers who have shipped over 300 projects for clients in Brazil, South Africa, Singapore, and the US. When we get an RFP, the ones we enjoy answering are the ones that ask about the team and the delivery rhythm, because those are the questions a serious buyer asks. If you are putting a list together and want a second opinion on which questions actually separate a good vendor from a good sales team, we are happy to help.
How many questions should a software RFP have?
Fewer than most people think. Ten to twenty focused questions beat a fifty-question form. You are filtering for real information, not compliance with a template.
Should I ask about pricing in the RFP?
Yes, but ask for the shape of the price, not just a number. What is included, what is excluded, and what changes the number. A number without those answers is meaningless.
What is the single most important RFP question?
Ask who exactly will build the project. Everything else follows from whether a real, named team is allocated to you.
Can I ask a vendor about past failures?
You should. A vendor that can describe a project that went wrong and what they did about it, without blaming the client, is far more useful than one with a flawless record.
What should I do with the responses?
Shortlist two or three and talk to them. The written answers get you the meeting. The meeting gets you the truth.
Tell us what you are building and where you are today. We typically reply within 24 hours.
