How to write a software development RFP that gets honest bids

Most software development RFPs are written like procurement documents and read like marketing requirements. The agencies that win them are the agencies best at writing proposals, not necessarily the ones best at shipping software. After receiving and writing more of these than is healthy, here’s the template we’d use if we were on the founder’s side of the table.

This is the document we’d hand to a founder before they sent the first email to an agency — including our own studio.

A good RFP filters out vendors who can’t think. A bad RFP filters in vendors who can write — which isn’t the same thing.

1. What an RFP is actually for#

A request-for-proposal does three jobs at once:

1. Communicate the work clearly enough that competent agencies can quote it honestly.
2. Filter out the wrong agencies before either side spends serious time.
3. Create a contract baseline so the eventual statement of work isn’t built on assumptions.

A surprising number of RFPs do only the first job. They describe the work, send it to ten agencies, and then the founder is buried in proposals that all look comparable but cost wildly different amounts. The filtering has to happen inside the document, not after.

2. The honest minimum: 7 sections#

Below is the structure that produces useful bids. You don’t need a forty-page enterprise RFP. You need this, well-written.

The last one is the most under-used. We’ll come back to it.

3. Context & problem — one page max#

Don’t describe the product. Describe the customer, the pain, and why you’re the one solving it. An agency that’s going to ship this well needs to know:

• Who is your target customer? Specific persona, not "small businesses."
• What painful workflow are they doing today that you’re replacing or improving?
• Why now? Is there a market shift, a regulatory change, a technology unlock?
• Why you? What unique vantage point or asset do you bring?

If you can’t answer those in one page, the RFP isn’t ready. The next eight weeks of work would have shipped against a fuzzy target and you’d blame the agency for it.

4. Scope — in and out, both explicit#

The single most expensive mistake in software RFPs is listing only what’s in. Without a list of what’s out, every agency interprets the gaps differently and you’ll receive bids that aren’t comparable.

A good scope section has two columns:

The "out" column is where you assert authority over your own scope. It tells agencies you’ve thought about the cuts, and it lets them quote against a real baseline. Our SaaS cost guide covers which items typically push the budget by 2–5× if you accidentally include them.

5. Constraints — the part most founders are afraid to write#

Founders are reluctant to share budget because they think it will anchor bids upward. The opposite is usually true.

Without a budget range, you get one of two things:

• Wildly varying bids that aren’t comparable.
• Lowball quotes from agencies hoping to upsell on change orders.

Give a range. Be honest about timeline. Name the stack constraints that are non-negotiable.

Budget range:    $60,000 – $90,000 for v1
Timeline:        Beta ready in 14 weeks, production launch in 20
Tech we own:     PostgreSQL (existing analytics), Stripe (billing)
Tech we’ll consider: Next.js, Remix, Laravel, Django
Tech we won’t use: MongoDB (we’ve been burned), microservices

An agency that can’t work within those ranges will tell you up front. An agency that secretly can’t but quotes anyway is the one that becomes a change-order story six months later.

Choosing between MERN, PHP, and Python? We wrote about picking a stack honestly.

6. Success criteria — the part that proves you’ve thought#

Anyone can build screens. The question is whether the screens move a number. Be explicit:

• What does “done” mean? A demo? A staging deployment? Production with five paying users?
• What metrics matter? Activation rate? Time-to-first-value? P95 latency?
• What does post-launch support look like? 30-day stabilisation? Ongoing retainer?
• What’s the acceptance test? Who signs off, and against what?

Agencies that take this section seriously will use it to challenge your assumptions. Agencies that don’t will skip it and quote against the screens instead.

7. Working model — assert your standards early#

The friction in an engagement isn’t about code. It’s about how the work happens. Be specific:

• Cadence. Weekly demos vs. monthly milestones?
• Communication. Slack channel? Async-first? One overlapping hour per day?
• Repository ownership. You own it from day one or hand-off at end?
• Tools. Linear/Jira? Figma? Notion?
• Senior engineer percentage. "We require at least 70% senior engineers on this project."
• Named technical lead. "We need to interview the lead before signing."

If you skip this section, the agency’s default working model becomes yours by accident. That’s how Tuesday-only standups and surprise PMs happen.

This connects directly to what we wrote in how to choose a software development agency — you’re putting those filters into the document itself.

8. Selection process — respect everyone’s time#

State the process up front, in writing:

- RFP sent:               <date>
- Questions deadline:     <date> (we&rsquo;ll respond to all in one email)
- Proposals due:          <date>
- Shortlist calls:        <window>
- Decision communicated:  <date>
- Engagement starts:      <date>

Tell bidders:

• Who the decision-makers are.
• How many agencies you’re inviting (be honest — "three" or "ten" matter).
• The criteria you’ll weight on (price? team? approach? portfolio?).
• Whether you’ll provide feedback to losing bidders. (You should. It’s the courteous standard.)

This is the section that separates founders worth working with from founders agencies will pad the price against. Agencies that have been burned by "we’ll get back to you" RFPs will quietly bid higher to compensate.

9. Open questions — the section that picks your partner#

This is the section nobody writes, and the most diagnostic one for you to evaluate bids.

List three to five things you’re not sure about and want the bidder to address.

Examples:

• "We’re unsure whether to use a managed auth provider (Clerk) or roll our own. What would you recommend, and why?"
• "We’d like usage-based billing but don’t know if it’s realistic for v1. What’s your view?"
• "We’re uncertain whether mobile-responsive web is enough, or whether we need a PWA. How would you decide?"
• "Our analytics needs are unclear. What would you recommend instrumenting on day one?"

Then read the responses carefully. Agencies that think will write thoughtful one-paragraph answers, often pushing back on the question itself. Agencies that pad will write generic "we’ll discuss in kickoff" non-answers.

The bidder who handles the open questions section best is almost always the right partner, regardless of price.

10. What to leave out#

A few things consistently make RFPs worse:

• A wireframe library. Show one or two if you must, but design is the agency’s job. Pinning screens too early is how you get the same product, more expensive.
• Mandatory tooling that isn’t actually mandatory. "Must use Jira" makes sense for a fortune-500. For most startups it just narrows the field.
• Excessive compliance requirements that you don’t actually need. SOC2, HIPAA, FedRAMP — these add 25–100% to the price. Don’t list them aspirationally.
• The NDA gate before sharing the RFP. Bidders will sign one if they reach the shortlist. Front-loading NDAs costs you the best agencies’ time.
• "Visionary," "synergy," "disrupt." They’re tells that the document was written by committee.

11. How to read the bids you get back#

Once proposals arrive, read them in this order:

1. The open-questions answers first. They tell you who’s thinking.
2. The named team. Who exactly is on your project? Background, role, dedication.
3. The milestone plan. Five to seven concrete deliverables with dates. Not three vague phases.
4. Pricing model. Fixed milestone, time-and-materials with cap, or retainer. Anything else is a yellow flag.
5. Risk acknowledgment. Did they name the three things that could break this build? If everything is "doable" with no risk mention, they haven’t read the RFP carefully.
6. The portfolio link. Last. Anyone can curate a portfolio.

If two bids are within 20% on price, pick the team. If they’re more than 30% apart, ask the lower one what they think the higher one is including, and vice versa. The conversation that produces is usually more diagnostic than the proposals themselves.

12. The 90-second test#

Before you send your RFP, give it to a non-technical friend and ask them to summarise back in 90 seconds:

• What is the company building?
• Who is the customer?
• What does success look like?
• What’s the budget range?
• When does it need to launch?

If your friend can’t answer those after one read, the agencies won’t either, and the proposals will reflect that.

13. A short template you can copy#

## Company & context
- Company:
- Stage:
- One-sentence product description:
- Target customer:
- Today’s painful workflow:
- Why now:

## Scope
### In scope (v1)
- ...
### Out of scope (v1)
- ...

## Constraints
- Budget range: $XX,XXX – $YY,YYY
- Timeline target: beta in N weeks, production in M
- Required tech:
- Preferred tech:
- Excluded tech:

## Success criteria
- Definition of done:
- Key metrics:
- Post-launch support expectation:

## Working model
- Demo cadence:
- Communication norms:
- Tools:
- Senior engineer ratio expected:
- Named lead engineer requirement: yes / no

## Selection process
- RFP sent: <date>
- Questions deadline: <date>
- Proposals due: <date>
- Shortlist calls: <window>
- Decision: <date>
- Evaluation weights: team / approach / price / portfolio

## Open questions
1. ...
2. ...
3. ...

Paste that, fill it in, send to no more than five agencies you actually want to work with. The proposals you receive will be 10× better than the ones generated by a generic procurement template.

14. How we read RFPs at SoftWebGrove#

When founders send us a well-written RFP, we’ll usually push back on the scope before quoting. When we get a vague one, we’ll write back with the questions the RFP should have answered. Either way, you get useful work product before you’ve signed.

If you’re drafting an RFP and want a second pair of eyes before you send it, tell us what you’re building. We’ll send notes within one business day — even if you don’t end up inviting us to bid.

FAQ#

Do startups actually need a software development RFP? For engagements under $25K, often no — a one-page brief and three conversations are enough. For anything larger, an RFP saves more time than it costs.

How many agencies should I invite to bid? Three to five. Fewer means thin comparison; more means everyone (including you) ends up burned out.

Should I share my budget in the RFP? Yes — as a range. Hiding it produces bids that aren’t comparable. See the constraints section above.

How long should an RFP be? Five to eight pages for most startup engagements. Twenty-page enterprise RFPs are noise; one-page briefs invite junk proposals.

Can an agency help me write the RFP? Yes — specifically, a different agency than the ones you’ll invite to bid. Or a fractional CTO, which we covered in fractional CTO vs agency.

Should I ask for free prototypes or design work in the RFP? No. Agencies that do free pre-work to win bids charge for it later. Pay for a small paid spike instead.

How long does the RFP-to-signed-contract process take? Three to six weeks for a well-run process. Founders who try to compress to one week get rushed proposals; founders who let it drag for three months lose the best teams to other engagements.