31 October 202611 min read

RFP for Web Development: How to Write One That Works

Three sealed manila envelopes in a row on a plain counter beside a small brass balance scale holding a folded document, a rubber stamp in front, and a beige clock with a glowing amber lamp at the edge.

A web development RFP is a document that tells agencies what you need built, how you will judge proposals and what a proposal must contain, so you can compare offers on equal terms. Write one when the project is big or risky enough to justify a documented selection and you already know roughly what you want. If you do not, define the problem first and write the RFP second. This guide gives you the structure, a template outline, a scoring method and the Swiss rules worth checking.

TL;DR

Use an RFP when budget, complexity or risk calls for a documented comparison of several agencies, and when the desired outcome is reasonably clear.
Cover ten parts: background, goals, scope, technical requirements, deliverables, timeline, budget, proposal format, evaluation criteria and submission rules.
Score proposals with weighted criteria and check references, instead of choosing on price or on the best pitch.
In Switzerland, public bodies must follow procurement thresholds. Private companies are free to set their own process, but data protection duties stay with you.

What a web development RFP is, and when it makes sense

SWICO, the Swiss ICT association, describes an RFP as a process in which the client asks suppliers to develop a solution that meets stated requirements and to price it. Suppliers may also propose first implementation ideas and possible solutions. The same guidance separates an RFP from a pitch: with an RFP, agencies are chosen on the basis of their offers and then work out the project in detail. It also warns that vague or missing agreements after either process can lead to disputes and dissatisfaction.

That last point is the real reason to write a good RFP. The document is not paperwork for its own sake. It is the first version of your contract conversation.

An RFP tends to pay off when three things are true, according to one practitioner guide: investment, complexity or risk is high enough to need a documented evaluation, the desired outcome is reasonably well defined, and several qualified agencies must be compared against the same criteria. Another guide notes that the format is especially useful for high-stakes, high-value projects and supports an objective, documented selection.

It is a poor fit when:

The project is small, for example a brochure site of a few pages. A short brief and two or three conversations are faster.
You are still unsure what the product should be. An RFP should support a defined decision, not replace the work of defining your needs.
You want the agency to shape the idea with you. A paid discovery phase or advisory engagement suits that better.

If you are unsure which side of that line you are on, spend a few days getting clear on the problem and the outcome you want before you write anything. A guide on how to compare agencies makes the same point from the buyer’s side: clarity about needs comes before any shortlist.

The ten parts of a web development RFP

No formula is fixed, but good RFPs share the same skeleton. Here is what each part does and how detailed it should be.

1. Company background and project context

Two or three paragraphs: who you are, what you sell, who your users are, and why this project exists now. Mention what exists today (an old site, a spreadsheet, a manual process) and what is wrong with it. Agencies price risk, and context lowers it.

2. Goals and success measures

State the business outcome, not the feature list. “Cut quote requests handled by email by half” is a goal. “A contact form” is a feature. The Swiss Association for Project Management (VZPM) advises deriving project goals from the organization’s goals, translating stakeholder needs into requirements and turning them into acceptance criteria that deliverables can be tested against. Write two or three measurable targets and you have the beginnings of those criteria.

3. Scope of work

List what is in and, just as important, what is out. Typical lines for a web project:

New build, redesign or replatforming of an existing site
Number and type of templates, rather than number of pages
Content migration: who writes, who moves, how much
Integrations with a shop, CRM, ERP, payment or identity provider
Languages: Switzerland often means German, French, Italian and English, which affects content, URLs and editing workflows
Hosting, launch support and post-launch maintenance

4. Functional and technical requirements

Switzerland’s federal HERMES project-management method is a useful checklist here. It says solution requirements cover specialist and technical needs, expected characteristics and functions, legal and regulatory requirements, operational, support and security requirements, and requirements for optimization and defect correction.

For a web project, translate that into:

Functional: what users and editors must be able to do
Technical: preferred stack or constraints, hosting location, browser and device support, performance targets
Security and operations: authentication, backups, monitoring, patching, who responds to incidents
Legal: data protection, accessibility, cookie and consent handling

A real Swiss example shows the level of detail that works. A Helvetas RFP for website support specifies testing, Core Web Vitals performance, documentation, proactive maintenance, monitoring, patches, TLS and backups. Notice that it covers life after launch, not only the build.

Mark each requirement as must-have, should-have or nice-to-have. Without that, every agency will price a different project.

5. Deliverables

Name the outputs you expect to receive: design files, working code in your repository, documentation, admin training, a test report, a handover session. If you want to own the source code and be able to move to another supplier, say so here. It is much easier to agree before the contract than after.

6. Timeline

Give the date you want to go live, any fixed external deadline (a campaign, a trade fair, a regulatory change), and whether the date is flexible. Adobe’s RFP guidance lists the project timeline, including whether the deadline is flexible, among the core elements. Also publish the timeline of the selection process itself: when questions close, when proposals are due, when you hold presentations, when you decide. Use real dates in your own document and keep them in one table.

7. Budget

Give a range. Many buyers hide the budget to “see what comes back”, and the result is proposals that cannot be compared: one agency prices a lean version, another a full one. A stated range lets agencies tell you honestly what fits inside it and what does not. The same guide recommends including an estimated budget range. Ask for pricing as a breakdown by phase or deliverable, and for how change requests are priced.

8. Proposal format

Tell agencies exactly how to answer, so you can lay proposals next to each other:

Company profile and team, with the named people who would work on your project
Understanding of the problem, in their own words
Proposed approach and architecture
Timeline with milestones
Price breakdown and payment schedule
Two or three comparable references you can call
Assumptions and exclusions

Set a page limit. Fifteen to twenty pages is plenty for most web projects.

9. Evaluation criteria

Publish your criteria and their weights in the RFP. It keeps agencies honest and keeps your own team consistent. The next section shows how.

10. Submission rules

Contact person, deadline for questions, deadline for proposals, file format, language and how long the offer must remain valid. Say whether you will share questions and answers with all bidders. Doing so is fairer and saves you answering the same query five times.

How to score the proposals

One guide to website RFPs recommends gathering consistent data from every agency, setting priorities and using weighted scoring, checking references, and having stakeholders score responses and record their notes. That is sound practice. A simple version:

Criterion	Example weight	What to look for
Understanding of your problem	20%	They restate your goals and spot risks you did not mention
Technical approach	20%	Fits your requirements, maintainable, no unexplained complexity
Team and continuity	20%	Named people, relevant experience, who stays through handover
Price and commercial terms	20%	Clear breakdown, change-request rules, code ownership
References and track record	10%	Similar projects, clients you can call
Post-launch support and handover	10%	Maintenance model, documentation, exit terms

Adjust the weights to your situation, then fix them before you open any proposal. Each evaluator scores alone first, then the group compares. Where scores differ widely, discuss why. The gap usually points to something unclear in the proposal or in your RFP.

Two habits improve results. First, ask who will actually do the work. Agencies sometimes send senior people to the pitch and juniors to the project. Second, treat a proposal that challenges your scope as a positive signal, as long as the reasoning is sound.

Swiss rules to check before you publish

Public procurement

If you are a public body or a contracting authority under the law, you cannot design the process freely. The federal Public Procurement Act allows a direct award for services under CHF 150,000, and requires an open or selective procedure from CHF 230,000 for services. For open-ended contracts, the value is calculated as the monthly remuneration multiplied by 48, which matters for support and maintenance agreements. Federal tenders are published on SIMAP, as the FDFA states for its own mandates. Cantons and municipalities have their own procurement rules, so confirm which applies to you with your legal team.

Data protection

If the agency will host or process personal data, you stay responsible for it. The Federal Data Protection and Information Commissioner says that when you outsource processing, you must select the processor carefully, give appropriate instructions and monitor where necessary. Put a short section in your RFP asking bidders where data will be stored, which subcontractors they use and how they handle incidents.

Accessibility

Federal administration web content and mobile apps must meet WCAG 2.1 level AA under the eCH-0059 Accessibility Standard version 3. Private companies are not bound by that standard, but asking for the same level is a reasonable, testable requirement, and it overlaps with good search practice. For the connection between the two, see this overview of web accessibility and SEO.

A template outline you can copy

Paste this into your document and fill each line. It works for a website and adapts easily to a web application or platform.

Introduction: company, project name, contact person
Background: current situation, users, what is not working
Goals: three measurable outcomes
Scope: in scope, out of scope, phases
Requirements: functional, technical, security, legal, accessibility, each ranked must/should/nice
Integrations: systems to connect, with their vendors and APIs
Deliverables: code, documentation, training, handover
Timeline: target launch, milestones, selection process dates
Budget: range, payment preferences, change-request terms
Proposal format: required sections, page limit, references
Evaluation: criteria and weights
Terms: validity of offer, confidentiality, intellectual property, data protection

Adapting it to a software project

For a web application or platform, add four things. First, user roles and the main workflows, written as short stories. Second, an explicit statement of how requirements may change: HERMES notes that traditional requirements are fixed in the concept phase, while agile ones begin as a product backlog, with changes documented through a change request when objectives, budget or timeframe move. Tell bidders which model you expect. Third, a non-functional section: expected load, uptime, backups and monitoring. Fourth, an exit plan: documentation, repository access and a handover period if you change supplier.

Common mistakes

Feature lists with no goals. Agencies then price features, not outcomes.
Hidden budget. You receive proposals ranging from CHF 20,000 to CHF 300,000 and learn nothing.
Too many bidders. Three to five well-chosen agencies give you better answers than fifteen rushed ones.
No time for questions. Good agencies will ask, and questions reveal who thinks hard about your problem.
Choosing on price alone. The cheapest proposal often leaves out what the others included.
Ignoring the maintenance phase. A site or app lives for years after launch. Ask for the support model and its cost now.

Where Ampersand fits

We are a small Zurich studio, and we respond to RFPs as well as helping teams who are not yet ready to write one. Senior engineers stay involved from the first consultation to handover, so the people who read your RFP are the people who build the project. If your requirements are still fuzzy, our Guidance plan is priced at 799 CHF per month, and once the site or app is live, Run & monitor is 750 CHF per month. You can see all our options, from websites and apps to automation, integrations and migrations, on the Ampersand pricing page.

FAQ

How long should a web development RFP be?

For most business projects, five to ten pages is enough. Include goals, scope, requirements, timeline, budget, proposal format and criteria. Longer documents tend to hide the key points and make agencies less likely to respond.

Should I include my budget in the RFP?

Yes, as a range. It lets agencies propose something realistic and makes proposals comparable. If you cannot name a figure, ask bidders to price two or three options of different size instead.

How many agencies should I send the RFP to?

Three to five is a practical number: enough to compare, few enough that you can read each proposal carefully and meet the finalists. Choose them from referrals and from past work similar to yours.

Is an RFP the same as a pitch?

No. According to SWICO, in an RFP agencies are selected on the basis of their offers and then detail the project, while a pitch is a different process. Either way, SWICO advises writing down clear agreements afterwards, to avoid disputes.

Sources

Talk to us

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading