How to write a software RFP that gets you useful proposals

If you have run a software agency RFP, you know the pattern: you send out a 20-page document, get back five 50-page responses, spend a week trying to compare them, and end up choosing based on a meeting that had nothing to do with the RFP itself. The whole process is performative. The agency that “wins” is usually the one with the best sales process, not the best engineering capability.

Most RFPs are bad. They ask the wrong questions, evaluate the wrong things, and produce noise instead of signal. This post is a practical template for writing a software RFP that actually filters effectively — designed for SMBs, mid-market companies, and any organization that is not bound by enterprise procurement rules.

We are an agency that responds to RFPs (selectively), so we have seen what works and what does not from both sides.

What an RFP is for

The honest purpose of an RFP is twofold:

Force the agency to commit to scope, price, timeline, and team in writing
Generate comparable artifacts so you can evaluate multiple agencies on the same axes

That is it. The RFP is not a discovery exercise (it cannot be — you do not have enough engineering depth on your side yet). It is not a way to make agencies do free design work (the good ones will refuse). It is a structured way to compare what you are buying.

What an RFP is not for

Common mistakes:

It is not a feature requirements document. You are hiring an agency to design the software with you, not asking them to bid on building exactly the features you have specified. If you have a complete feature spec and want it built, that is a different procurement (a fixed-bid build, not an RFP).
It is not a security questionnaire. SOC 2 reports, security policies, compliance certifications — these are separate documents requested separately, not embedded in the RFP.
It is not a vendor stress test. Asking 100 questions just to see who will answer them all does not select for engineering capability; it selects for proposal-writing labor.
It is not a way to outsource scoping. “Write us a proposal for our project” without a clear problem statement asks the agency to do your discovery work for free. The good agencies will not.

The structure that works

A useful RFP has six sections, each short. Together they should fit in 4–8 pages.

1. The problem statement (1–2 pages)

What business problem are you trying to solve? Who is affected? What does success look like?

This is the most important section and the one most RFPs skip. Without a clear problem statement, every responding agency has to guess at what you actually want — and they will guess differently. The result is incomparable proposals.

A good problem statement is concrete:

“Our scheduling system runs on Excel spreadsheets that are emailed between 12 dispatchers. Errors and delays are costing us approximately $200k/year in missed bookings. We need a web-based scheduling system that the dispatchers can use, integrates with our existing CRM, and reduces our error rate by at least 50% within 6 months of launch.”

Compare to a bad one:

“We are looking for a partner to help us digitally transform our operations through innovative technology solutions.”

2. Constraints and requirements (1 page)

What constrains the solution?

Compliance: HIPAA, SOC 2, PCI-DSS, FedRAMP, etc. State the framework explicitly.
Integrations: which existing systems must this integrate with?
Stack constraints: do you have a required tech stack? (Most SMBs should not — let the agency choose. State a constraint only if you have a real reason.)
Hosting: are you required to host on a specific cloud (AWS, Azure, GCP) or in a specific region?
Authentication: do you have an existing identity provider you must integrate with?
Data: what is the approximate data volume and growth rate?

State only what is genuinely required. The more constraints you add, the smaller the universe of possible agencies and approaches — sometimes for good reasons, sometimes for ones that get in the way.

3. What you are asking for in the response (1 page)

Be explicit about what you want from the agency:

A proposed approach: how would they tackle this problem? Architecture sketch, key decisions.
A discovery plan: what would they do in a paid discovery phase?
A team composition: which specific people will work on this? Names, not titles.
A timeline estimate: rough phases, with milestones.
Pricing: discovery cost, build cost range, ongoing maintenance cost. Specific numbers, not “investment ranges.”
2–3 case studies: prior work that resembles this project. Real ones, with technical specifics, not testimonials.
References: 2 client references from work in the past 18 months.

Resist the urge to ask for more. Each additional ask is more proposal labor that will not change your decision.

4. The selection criteria (½ page)

Tell the agencies how you will evaluate the proposals. Be specific. Examples:

Quality of approach (35%)
Team experience with the specific stack (25%)
Pricing (20%)
References (10%)
Cultural fit (10%)

This forces you to commit to what you actually care about. It also signals to the agencies what to emphasize. If pricing is 20%, the agency knows the cheapest proposal will not automatically win.

5. Process and timeline (½ page)

When are responses due? When will you make a decision? When will the engagement start?

Realistic timeline:

Send RFP: day 0
Q&A period (agencies submit clarifying questions in writing): days 0–10
Q&A responses sent to all agencies: day 11
Proposals due: day 21
Shortlist of 2–3 agencies invited to present: day 28
Final decision: day 35

Anything significantly faster signals chaos. Anything significantly slower signals indecision and will lose you the better agencies.

6. Background and contact (½ page)

Who is your company? Who is the buying decision-maker? Who is the technical decision-maker? How should the agency reach out?

Include:

Brief company background
Industry and size
Key contact for the RFP (name, email, phone)
Q&A submission method (email is fine; do not require a specialized portal)

What to leave out

Things many RFPs include that produce noise:

Boilerplate legal: NDAs, vendor terms, payment terms. Send these separately to the shortlist, not in the RFP itself.
Vendor questionnaires: financial stability, insurance, certifications. Request after shortlisting.
Detailed feature lists: too much detail forces the agency to bid on your spec rather than propose a better solution.
Technical requirements that are actually constraints: “must use AWS Lambda” is a constraint disguised as a requirement; if you have flexibility, do not commit to it in the RFP.
Long lists of “nice to have” features: these inflate proposals without changing the decision.

How to evaluate the responses

Once you have proposals back, score them quickly on the criteria you committed to. Do not get pulled into reading every word of every 50-page proposal. The signal is in a few specific places:

Did they understand the problem? Read the proposed approach section. Does it address the actual problem statement, or does it generic-platitude through it?
Do they have specific case studies? Generic case studies signal a sales-led organization. Specific case studies with technical details signal an engineering-led one.
Are the named team members senior? If the proposal lists “a senior architect” without a name, you are getting a stranger after signing. If it names specific people, you can vet them.
Is the pricing specific or vague? “Investment range $200k–$1M” is not pricing; it is hedging. Look for specific numbers.
Does the timeline make sense? Be skeptical of any agency that quotes a much shorter timeline than the others. They are either underscoping or planning to scope-creep you mid-build.

Filter to 2–3 finalists, do an in-person or video meeting with each (with the actual engineers, not just sales), and choose.

A common pattern: skip the formal RFP

For most SMB software projects, a formal RFP is overkill. A more efficient path:

Identify 3–5 candidate agencies through search, referrals, and directory research
Send each a brief problem statement and request a 30-minute introductory call
Have the call with the engineer who would do the work, not just sales
Ask for a paid discovery proposal from the 2–3 you most resonate with
Pick one based on the discovery output, not based on a competing-proposals process

This approach costs you a few thousand dollars per discovery (typically $5–15k from a boutique Tampa Bay agency) but produces much better information than any RFP. The discovery output is a written technical plan you own — and it is concrete enough to make a real decision.

If you do choose to run a formal RFP, the structure above will get you better results than the bloated templates floating around online.

Final note

Most software RFPs are exercises in checking boxes. The good ones force the agency to commit to specific decisions in writing, generate comparable artifacts, and filter for engineering substance over sales polish.

If you are about to run an agency selection process and want a sanity check on your RFP — or want to know whether an RFP is even the right approach for your project — email us a paragraph about what you are evaluating. We will tell you honestly whether we are a fit, whether you should run a formal RFP, and what we would do in your position.