Most RFP templates in circulation were written before AI-augmented delivery was a normal part of how software gets built, and it shows. They ask about timeline, team structure and pricing, and say nothing about who owns AI- generated output or how a vendor's AI usage affects what you're being billed for. This one is current, genuinely usable without providing your email address for it, and vendors can actually quote against it.
Why this template, and its honest classification
We're not going to pretend this is purely a public service. A good template travels. It gets shared inside procurement teams, referenced by other vendors, picked up by anyone drafting their first serious RFP. That's the point. What makes it worth using regardless of who wrote it: the sections below are the ones that actually produce comparable, quotable proposals, and the two 2026-specific additions close real gaps in what older templates ask.
The template
1. Project overview
- What you're building, in plain language, not a feature list yet but the problem it solves.
- Current state: greenfield, existing system, or an AI-tool-built prototype needing production hardening (see what that specifically requires if that's your situation).
- Target users and rough scale expectations.
2. Scope and requirements
- Core functional requirements, prioritised: must-have versus nice-to-have, explicitly separated.
- Integration requirements with existing systems.
- Non-functional requirements: performance, availability, compliance obligations that apply to your industry or region.
3. Timeline
- Desired start date and any hard deadlines, with the reason stated if there's a real one (a launch event, a regulatory date, a budget-cycle boundary).
- Whether you need working software early, and if so by when, rather than a single delivery at the end.
4. Budget
- A stated range, even a wide one. An unstated budget produces either wildly over-scoped proposals or vendors declining to bid rather than guessing. See what custom software actually costs in 2026 if you need a market range to set that number against before you write it down.
5. Team and engagement model
- Do you want a dedicated named team, or is a flexible resourcing model acceptable?
- Fixed-scope, dedicated-team, or retainer: ask the vendor which model fits what you've described and why, rather than specifying one yourself if you're not sure.
6. AI-usage disclosure, a 2026 addition
- How does the vendor use AI tooling in their own delivery process?
- Does AI-accelerated work affect time-and-materials pricing? Ask directly, because this is exactly the gap our vendor-vetting checklist flags as one incumbent RFPs still miss.
- If the deliverable itself includes AI features, what disclosure and compliance obligations (e.g. EU AI Act Article 50, if applicable) does the vendor already build for?
7. IP and code ownership, a 2026 addition
- Require the vendor to state, explicitly, whether their standard contract uses present-tense assignment ("hereby assigns") or a future promise ("agrees to assign"). The difference matters more than it looks like it should. Make the vendor answer in the RFP response itself, not after you've signed.
- Ask whether AI-generated portions of the deliverable are explicitly covered by the assignment clause, or only "work product" in a way that predates the question.
8. Evaluation criteria
- State how proposals will be scored, and by what weighting, before you send the RFP, not after responses arrive. This keeps the evaluation defensible and keeps vendors from guessing what you actually care about.
9. Response format and deadline
- A consistent structure every vendor must follow, so responses are comparable rather than each vendor choosing their own format.
- A stated deadline: two to three weeks is a reasonable default for mid-sized projects, long enough to scope properly, short enough to keep momentum.
Using this template
Copy the nine sections above into your own document, fill in the specifics of your project, and send it to every vendor on your shortlist in the same format. The two 2026 sections (AI-usage disclosure and code ownership) are the ones most likely to separate vendors who've actually thought about this from vendors reciting a pre-2023 answer to a 2026 question.
Send it to us
We respond to RFPs in five business days, with named engineers reviewing the actual scope, not a templated proposal deck assembled by someone who won't be doing the work. Send us your RFP, structured however you like; this template is the one we'd suggest, not a requirement to use it.
Common questions
Two sections most templates still lack: an AI-usage disclosure requirement (ask vendors how they use AI in delivery and whether that affects pricing) and an explicit code-ownership and IP-assignment requirement, specifying present-tense assignment language rather than leaving it to the vendor's standard contract.
Long enough for a serious vendor to scope properly, short enough to keep your timeline moving. Two to three weeks is a reasonable default for mid-sized projects. State it explicitly in the RFP; an unstated deadline produces inconsistent response quality across vendors.
Generally yes, even a wide one. Withholding budget entirely tends to produce either wildly over-scoped proposals or vendors declining to bid rather than guessing wrong. A stated range, even "$80,000-$150,000," gets you comparable proposals.
Structure wins for comparability. A free-text RFP lets each vendor answer a slightly different question, which makes proposals genuinely hard to compare side by side. A structured template with the same sections for every vendor produces responses you can actually evaluate against each other.