How to Write an RFP for a Custom Web Application (With a Reusable Template)

A good request for proposals does one job: it makes competing bids genuinely comparable. Most RFPs fail at this, because they describe features instead of outcomes, hide the budget, and leave the exclusions unwritten. This is a section-by-section template you can copy, with the reasoning behind each part.

We respond to these documents regularly, so this guide is written from the receiving end. The advice that follows is aimed at getting you accurate, comparable pricing, including from vendors who are not us.

Diagnosis

Why most RFPs produce bad bids

Three failures account for nearly all of it.

Features instead of outcomes. "The system shall have a dashboard" tells a vendor nothing about scope. "A branch manager must be able to see today's bookings, unpaid invoices, and staff availability on one screen without exporting anything" can be estimated to within a few hours.

Hidden budget. Without a range, one vendor prices a $6,000 solution and another a $60,000 one. Both may be reasonable answers to a question you did not ask precisely enough, and you cannot compare them.

No exclusions. Every dispute in a software project happens at a boundary. If content migration, staff training, or third-party licence costs are unaddressed, each vendor makes a different silent assumption, and the cheapest bid is usually the one that assumed the most work away.

Section 1

1. Business context

Half a page. What your organisation does, who your customers are, what problem prompted this project, and what will be measurably different if it succeeds. Vendors who understand the "why" propose better solutions than the one you specified, and that is the value you are paying for.

State the success measure explicitly: "reduce time to process an application from three days to under four hours", or "enable customers in three currencies to pay without manual invoicing". A vendor that cannot connect its proposal to that measure has not read your document.

Section 2

2. Current state

List what exists today: current website and its platform, internal systems, spreadsheets doing load-bearing work, the SaaS tools in use with their monthly costs, and roughly how many people touch the process daily. Include data volumes: 500 records and 5 million records are different projects.

Be candid about what is broken. Vendors discover it in week two anyway, and finding out late is what turns fixed-price projects into change requests.

Section 3

3. Functional requirements

Write each as a user outcome, grouped by role, and marked Must, Should, or Could. The prioritisation matters more than the list: it lets a vendor propose a phase one that fits your budget instead of declining to bid.

Section 4

4. Non-functional requirements

The section most often omitted and most responsible for cost surprises. Cover, briefly and in plain terms:

• Performance: expected concurrent users, peak periods, and the slowest acceptable page load on a mid-range phone over 3G.
• Availability: what uptime you need and what a genuine outage costs you per hour.
• Security and privacy: which regulations apply: GDPR, the Kenya Data Protection Act, PCI scope if you touch card data, and where data may legally reside.
• Accessibility: the standard you require, typically WCAG 2.2 AA, and whether it is contractual.
• Browsers and devices: what you genuinely support, informed by your analytics rather than by habit.
• Localisation: languages and currencies at launch, and which are planned later.

Section 5

5. Integrations and data

For each system that must exchange data, state its name, what must flow in which direction, how often, and whether it has a documented API. Note explicitly where an integration is with a legacy system that has no API. That single fact can move a quote by thousands of dollars, and vendors that discover it late will raise a change request.

Include data migration as its own line: how many records, from which system, in what format, and how clean they are. "The data is messy" is an honest and useful sentence to write.

Section 6

6. Explicit exclusions

State plainly what the vendor is not responsible for. Typical exclusions worth naming: content writing, photography, translation, third-party licence fees, hardware, ongoing hosting costs, data cleansing, and staff training beyond an agreed number of sessions. Whatever you leave unstated, you will pay for twice, once in your own time and once in a change request.

Section 7

7. Commercial terms

Set your terms rather than accepting theirs. State the contracting model you prefer, the payment schedule tied to deliverables, the warranty period for defects after launch, and, most importantly, the ownership position: all intellectual property assigns to you on final payment, and the repository lives in your account throughout.

Ask each vendor to price year-one support separately from the build. A build quote without a support quote is half a price.

Section 8

8. Evaluation criteria

Publish the weightings. It focuses proposals on what you care about and makes your eventual decision defensible internally.

The hard part

The budget question

Publish a range, such as "$8,000 to $15,000 for phase one", and say what would justify the top of it. Three things then happen. Vendors who cannot deliver at that scale decline early, saving everyone weeks. Vendors who can compete on scope rather than guessing at it. And you find out immediately whether your expectations and the market agree, which is information worth having on day one rather than day forty.

Decision

Scoring the responses

Score independently before discussing. Have each evaluator complete the matrix alone, then compare, group scoring converges on whoever spoke first. Where scores diverge sharply, that is the question to take back to the vendor.

Then apply two sanity checks. First, the outlier check: if one bid is 40% below the others, find the missing scope rather than assuming efficiency. Second, the reference check: speak to a client whose project went badly, and ask the vendor to introduce you to one. How a vendor handles that request is the most informative thing you will learn in the entire process.

$100 for a one-hour session, billed at $25 per 15 minutes with a one-hour minimum. You choose your time on Calendly immediately after checkout. Pay by card or M-Pesa.

FAQ

Frequently asked questions

What should an RFP for a web application include?

Eight sections: business context and the problem being solved, current-state systems, functional requirements written as user outcomes, non-functional requirements such as performance and security, integrations, explicit exclusions, commercial terms including ownership and support, and the evaluation criteria with weightings. Anything else is padding.

Should I put my budget in the RFP?

Yes, publish a range. Withholding budget does not get you better prices; it gets you proposals that are not comparable, because each vendor guesses at a different scale of solution. A published range lets vendors compete on what they will deliver for that money, which is the comparison you actually want.

How long should an RFP be?

Eight to fifteen pages for a project under $50,000. Longer documents attract vendors with proposal departments rather than vendors with engineers, and they reliably reduce the number of thoughtful responses you receive.

How many vendors should I invite?

Three to five. Fewer than three gives you no comparison; more than five means you cannot evaluate any of them properly, and serious vendors decline processes with large invitation lists because their win probability does not justify the effort.