AXENTED — Blog Article

How to Write a Software RFP That Attracts Good Vendors (Not Just Cheap Ones)

Most software RFPs are written by people who have never had to respond to one. The result is a document that's too detailed where it doesn't matter and too vague where it does — leading to proposals that are either wildly inconsistent or uniformly low-quality. Getting a useful set of vendor proposals requires a different kind of RFP.

This is what that looks like.

Lead With the Business Problem, Not the Technical Specification

The most common RFP mistake is front-loading technical requirements before context. A vendor reading "build a REST API that returns paginated results with support for filtering by date range" has no idea what problem this solves, who the users are, or what success looks like. Without that context, they're optimizing for meeting the spec, not for solving the problem.

Start the RFP with a plain-language description of the business problem. Who has this problem, how often, and what does it cost them today? What would a successful solution change about their experience? That context allows a good vendor to tell you whether your technical specification actually addresses the problem — which is more valuable than knowing they can execute the specification literally.

Be Explicit About What You Don't Know

Buyers often write RFPs that imply more certainty than actually exists, because they worry that uncertainty will produce higher proposals. The opposite is true. A vendor who sees a buyer acknowledging uncertainty will propose an approach that manages that uncertainty — phased delivery, a discovery phase, explicit decision points. A vendor who doesn't know uncertainty exists will propose a fixed-scope fixed-price engagement that will need to be renegotiated when the uncertainty surfaces mid-project.

Include a section that explicitly states the open questions: What we still need to figure out. What decisions haven't been made. Where we expect requirements to evolve. Vendors who handle that section well are usually the vendors worth hiring.

Describe the Team You Have, Not Just What You Need

Software projects are joint endeavors. The vendor's ability to execute depends heavily on what the client brings to the engagement: technical context, decision-making authority, stakeholder availability, existing infrastructure. An RFP that describes only what the vendor needs to build and says nothing about what the client will provide is incomplete information.

Include: who on your team will be the primary point of contact, how quickly your team can review deliverables and provide feedback, what access the vendor will have to your systems and existing code, and how decisions get made internally when requirements change. That information lets vendors scope the engagement accurately.

Evaluation Criteria That Actually Differentiate

Scoring vendors on price and years of experience produces a selection process that rewards whoever quotes lowest and longest. These criteria don't predict project success. The factors that do: how well the vendor diagnosed the real problem versus accepted the stated one, whether their proposed approach reflects the actual constraints of your context, and whether the people who will do the work were part of the proposal process.

Ask to see examples of projects that went wrong and how the vendor handled them. That question produces more signal than any reference check.

Scope What Must Be True, Not Every Detail of How

An RFP that specifies every technical decision leaves no room for a vendor to apply their expertise. The best vendor proposals are ones where the vendor read your RFP, understood the constraints that actually matter, and came back with an approach that's better than what you would have specified on your own.

Specify outcomes and constraints, not implementation details. "Users must be able to complete checkout in under three steps on mobile" is a useful requirement. "Use React with TypeScript and follow the Airbnb style guide" is a constraint that should only appear if it genuinely matters to the project.

Red Flags in Vendor Responses

Three proposal patterns predict bad projects: a proposal that accepts every requirement without qualification (no vendor who has done complex software actually agrees with everything the first time), a price that's significantly lower than all other proposals (someone underestimated, and the reckoning happens post-signature), and a team described in the proposal that's different from the team who would actually do the work.

The vendors worth hiring push back on things, price accurately, and let you meet the engineers before you sign.