Article summary
More and more founders and teams are reaching out to us with a request for proposal (RFP) in hand. Increasingly, there’s a pattern behind it: they built a proof of concept with AI, then asked AI to turn it into an RFP. The document is lengthy, structured, and confident.
I understand the instinct. The prototype works, so the requirements feel settled. An RFP isn’t always necessary to find a great software partner, and this particular path can overstate what’s required or expected. The spec inherits the certainty of a working demo without inheriting any evidence that a market wants it or that it will work at scale. A PoC that works for you is not proof that a product will work for buyers. The questions that decide that (who else has this problem badly enough to pay for it, what will they pay, how is this positioned against the way they solve it today) aren’t in the document at all.
RFP vs. RFI
I understand the instinct. But before the RFP, consider the RFI.
A Request for Information (RFI) asks for less and reveals more. You share the high-level vision. What is this? What problem does it solve? Why is now the right time to solve it? Why are you the right person or company to solve it?
That’s often enough for a software partner to give you something real: relevant past experience, how they’d recommend approaching the problem, even a budget range. You learn how each firm thinks before anyone has speculated on details neither of you can know yet. And you come away with a partner, or a very short list worth going deeper with.
The Request for Proposal (RFP) is where you go deeper. Now you’re into outcomes, capabilities, and the constraints you’re working within. Budget, timeline, funding, how success will be measured. That context lets a short list of partners get specific: a plan, a timeline, a picture of how you’ll work together. And because it’s a short list, there’s room for actual conversation. Both sides bring expertise, questions, and recommendations, and you find out whether there’s a mutual fit rather than just a matching quote.
Why the RFI Gets Skipped
Sequenced this way, each document does the job it’s built for. The RFI finds the partners who understand your problem. The RFP tests whether one of them can deliver against your constraints.
The RFI gets skipped because ideating on the product and its features is the exciting part. But a beautiful product that misses the mark on the problem, or solves a problem no one has, is devastating. All that effort, and the market shrugs.
No partner can buy you product-market fit. What the right one brings is a way to mitigate the risk of missing it. They thoughtfully challenge the assumptions that have to be true for this to work. They move intentionally to clarify what matters before any designs are created or any code is written.
So if you’re about to write an RFP, try writing the RFI first. Vision, problem, timing, why you. See who responds with understanding instead of just a number.
One caution as you run either process: the partner who can nail the homework assignment may not do well in the moment, and may not foster the high trust and high communication a true partnership needs. Don’t skip the conversations. Those discussions will tell you what kind of partner you’ll be side by side with.
We’ve believed this at Atomic for a long time. Our founder wrote years ago that you should use the RFP to select the best vendor, then collaborate with that partner to build the best project. Still true.