Website Design and Development Company - RFP Questions that Work

RFPs for software are notorious for producing the wrong outcome: a vendor that looks good on paper, ships something “done,” and leaves you with a platform that is fragile, expensive to change, or impossible to operate.

If you are evaluating a website and app development company, the highest leverage move is not asking for more pages of boilerplate. It’s asking questions that force clarity on how the vendor thinks about risk, architecture, delivery, and ongoing ownership.

Below is a set of RFP questions that work, meaning they reliably separate:

• teams who can build and evolve business critical systems

• teams who mainly sell delivery motion and output

Why most RFP questions fail (and what to do instead)

Many RFP templates overweight surface level signals: years in business, a long tech stack list, and generic promises about “agile.” Those details matter less than you think.

What you actually need to know is whether the vendor can:

• understand your workflows and constraints (not just the spec)

• design a system that won’t require a rewrite in 12 to 24 months

• ship safely, with a plan for quality, security, and operations

• communicate trade-offs before those trade-offs become incidents

Good RFP questions do two things:

1. They demand evidence, not just claims.

2. They reveal how the team makes decisions when requirements conflict (time vs quality, speed vs safety, flexibility vs simplicity).

Start by anchoring the RFP on outcomes (not features)

Before you ask vendors to propose solutions, give them enough context to propose responsibly. Otherwise you reward guessing.

Here is a simple checklist of inputs that improve proposal quality without bloating the RFP.

Once you provide that, the questions below will do real work.

RFP questions that work (by category)

Use the categories as sections in your RFP. You can ask all of them, but you will often get better responses by selecting the ones that match your risk profile (regulated workflows, payments, complex permissions, legacy migration, mobile offline, and so on).

1) Discovery and product thinking

Question: “Describe your discovery process. What artifacts do you produce, and what decisions do those artifacts enable?”

Look for: clear deliverables (workflows, domain model, integration map, data risks, phased plan), and a tight connection between discovery and build.

Question: “Tell us about a time you pushed back on a client request. What did you recommend instead, and what happened?”

Look for: comfort with trade-offs, not performative agreement.

Question: “What assumptions would you challenge in our RFP, and what questions do you need answered before estimating?”

Look for: vendors who ask about operational realities (support load, data quality, compliance, internal ownership), not only UI.

2) Architecture and maintainability

Question: “How do you approach architecture for systems that must last (2 to 5 years) without a rewrite?”

Look for: modular boundaries, migration strategy, versioning approach, and evidence they’ve lived through scaling and team changes.

Question: “Describe how you document technical decisions. Do you use architecture decision records (ADRs) or an equivalent?”

Look for: a lightweight, consistent way to record “why,” not just “what.”

Question: “How do you handle data modeling changes over time, including backfills and zero downtime migrations?”

Look for: safe migration practices, background jobs, feature flags, and staged rollouts.

Question: “What is your approach to integrations (Stripe, QuickBooks, Google APIs, OAuth, AWS, etc.) when third parties are unreliable or rate limited?”

Look for: idempotency, retries, queuing, observability, and clear failure modes.

3) Security, privacy, and compliance readiness

Security answers should reference established guidance, not vibes. OWASP is a common baseline for web application risk, and using it in an RFP response is a good sign.

You can reference OWASP Top 10 as a shared language for common classes of vulnerabilities.

Question: “What security practices are standard in your delivery process (authentication, authorization, secrets management, dependency updates)?”

Look for: least privilege access, secret storage, dependency scanning, secure defaults.

Question: “How do you handle authorization in complex apps (roles, permissions, multi-tenant access)?”

Look for: an explicit model, not ad hoc checks spread throughout the codebase.

Question: “Describe your approach to logging and audit trails for sensitive actions. What do you log, and what do you avoid logging?”

Look for: auditability without leaking sensitive data.

Question: “If we need accessibility compliance, what standards do you build toward, and how do you validate?”

Look for: familiarity with WCAG expectations, and a testing approach.

4) Delivery, predictability, and project management

Question: “How do you estimate and plan when requirements will evolve? Provide a sample plan format (phases, milestones, acceptance criteria).”

Look for: phased delivery, explicit assumptions, and a way to renegotiate scope without drama.

Question: “What does your weekly communication cadence look like, and what happens when a milestone is at risk?”

Look for: early warning systems, not last minute surprises.

Question: “How do you structure environments (dev, staging, production) and approvals to reduce release risk?”

Look for: a deployment pipeline, and clarity on who can approve what.

5) Quality engineering and testing

Question: “What is your testing strategy (unit, integration, end-to-end), and what do you consider the minimum bar before shipping?”

Look for: intentionality. Not everything needs exhaustive tests, but critical workflows should be protected.

Question: “How do you prevent regressions during rapid change (test coverage, code review standards, CI checks)?”

Look for: a real process, plus examples.

Question: “How do you validate performance and reliability before launch? Do you set performance budgets or run load tests when appropriate?”

Look for: measurable thresholds and environment parity.

6) Operations, support, and long term ownership

This is where many projects fail after “successful” delivery.

Question: “What is your handoff process? What documentation and runbooks do we receive?”

Look for: operational readiness, not just a repo link.

Question: “What is your approach to monitoring and incident response? What tools do you typically use, and what metrics matter?”

Look for: clarity on observability (errors, latency, job failures, third party failures).

Question: “How do you handle upgrades over time (framework updates, dependencies, infrastructure changes)?”

Look for: planned maintenance, not deferred panic.

7) Team composition and senior oversight

If you want predictable delivery, you need to know who is actually doing the work.

Question: “Who will work on our project (by role), and how much of the work is done by senior engineers?”

Look for: named roles, stability, and senior accountability.

Question: “What parts of the work do you outsource or subcontract (if any)?”

Look for: transparency.

Question: “What is your approach to code review, and who approves architectural changes?”

Look for: a clear technical leadership model.

Ask for evidence, not promises

A simple way to improve your RFP is to require 2 to 3 examples of real artifacts. Even redacted samples are useful.

Good evidence requests include:

• a sample technical plan (phased milestones with acceptance criteria)

• a sample pull request showing code review standards

• a sample runbook or launch checklist

• a sample architecture decision write-up (ADR or equivalent)

If a vendor can’t show how they work, you are betting on marketing.

A practical scoring matrix you can use

You do not need a complex procurement model. You do need weights that reflect your real risk.

Adjust weights based on what would hurt you most. Regulated workflows and payments usually push security and operations higher.

Red flags that show up in “good looking” RFP responses

Not every red flag is a deal breaker, but these should trigger follow-up questions.

• “We can build anything” with no discussion of trade-offs or constraints

• Estimates presented as certainty, without assumptions

• Vague testing language (“we test thoroughly”) with no specifics

• No plan for maintenance, upgrades, or operational ownership

• A senior team on the sales call, but unnamed delivery team members

If you are specifically hiring for Laravel (or a Laravel-based CMS)

If your platform is Laravel, it’s reasonable to ask ecosystem specific questions. These are useful even if your buyers are not deep in the framework.

Question: “What Laravel conventions do you follow to keep the codebase idiomatic and readable for future teams?”

Question: “How do you approach background jobs, queues, and long running tasks, and how do you monitor failures?”

Question: “What is your policy for keeping Laravel and dependencies updated over time?”

If a vendor claims deep Laravel expertise, you can also verify partner status through the official Laravel Partners directory.

How to use these questions without turning the RFP into homework

RFP fatigue is real. To keep responses high quality:

• limit each category to 3 to 5 questions that match your risk

• require at least 2 concrete examples (artifacts or case studies) in total

• schedule one technical deep dive with the people who will actually build

You are not trying to extract free consulting. You are testing for decision making quality.

When you want a vendor who reduces risk, not just ships code

If your system is already business critical, or you are painfully aware your current platform is not cutting it anymore, your RFP should reward teams that are senior-led, opinionated, and operationally pragmatic.

Ravenna is a boutique development firm in the Seattle area focused on Laravel, Statamic, and React Native, and we’re an official Laravel Partner. If you want an RFP response that engages with the hard parts (architecture, migration risk, reliability, and long term ownership), you can start a conversation at Ravenna.