Enterprise decision
Shopify Plus RFP: make agency proposals genuinely comparable
Updated
A strong Shopify RFP does not prescribe every eventual solution. It creates comparable starting conditions by separating goals from constraints, documenting systems and data, naming critical processes, defining acceptance and operations, and requiring the same assumptions from every bidder. This exposes differences in architecture, team and risk rather than price alone.
This checklist is for replatforming and larger relaunch programs. A single theme module or small optimisation sprint rarely benefits from a full RFP.
What must be decided before the RFP is sent?
Start with the business outcome that should change. An RFP without an outcome becomes a feature list nobody can prioritise. Revenue, markets, operating cost, release speed or B2B capability need a clear direction.
The decision frame matters too. Budget range, target launch, available internal roles and fixed system contracts influence the solution. Hide those facts and every bidder will estimate a different project.
What belongs in the technical baseline?
Describe the platform, stores, markets, catalogue size, order volume and every connected system. For ERP, PIM, WMS, CRM and finance, the product name is not enough; data objects, direction, frequency, ownership and known exceptions matter.
Custom functionality needs examples from real operations. The phrase “complex pricing logic” is not testable. Concrete examples of customer types, price lists, approval flows and returns show what the architecture must actually support.
| Area | Information required | Why it matters |
|---|---|---|
| Storefront | Themes, markets, languages, domains | Shapes architecture and rollout |
| Catalogue | Products, variants, media, metafields | Shapes mapping and import |
| Commerce | B2B, POS, subscriptions, bundles | Shapes platform and app scope |
| Systems | ERP, PIM, WMS, CRM, finance | Shapes integration work |
| SEO | Indexed URLs, rankings, redirect history | Shapes migration risk |
| Operations | Release, support, monitoring, roles | Shapes the post-launch model |
How do you state requirements without prescribing the solution?
State the outcome and boundary first. Instead of requiring a named app, say that merchandisers must manage rules without a deployment, with version history and changes visible within ten minutes.
Technical mandates belong only where they are genuine company constraints: existing contracts, security, data residency, identity, available APIs or a binding operating model. Everything else should remain open to a justified approach.
Every critical requirement needs
- a business purpose
- a real example process
- a measurable acceptance condition
- a named internal owner
- a label as mandatory, preferred or open
Which questions expose agency quality?
Ask about decisions, not only references. Strong answers identify assumptions, open questions, risks and alternatives. An agency that knows every solution before discovery has probably not priced the unknown parts.
Request the actual team structure as well: who works in discovery, architecture, development, QA and after launch? Names, roles and availability matter more than a broad list of specialists who may never join the project.
How should proposals be scored?
Score against fixed criteria and agree the weighting before bids arrive. Price matters, but without scope clarity it is not comparable. Architecture, risk treatment, team, delivery and operations need visible weight beside it.
Separate assumptions from commitments. A low price may rely on clean source data, finished APIs or internal content work. Put those assumptions in the same table as the price so the difference does not emerge only after signature.
What belongs in the final round before award?
The final round should not be another sales presentation. Work through one real process, one integration flow and one critical migration case with each finalist. This reveals how the team structures questions and records decisions.
Before award, align scope, exclusions, acceptance, roles, change control and operations. Remaining unknowns stay as named contractual risks or move into a paid discovery before build.
FAQ
Frequently asked questions about Shopify RFPs
How long should a Shopify RFP be?
Long enough to create a shared baseline, but not a catalogue of every imaginable feature. Strong RFPs separate outcomes, landscape, critical processes, acceptance and scoring, with detailed inventories kept in appendices.
Should the budget be included?
A realistic range improves comparability. Without it, bidders propose different programmes or invest in designs that cannot fit the eventual constraint. The range can be paired with explicit options and assumptions.
Do we need discovery before the RFP?
Usually yes when integrations, markets or custom logic are unclear. A short independent discovery stops each bidder filling the same gaps differently and creating proposals that only appear comparable.
How many agencies should be invited?
Enough for a real choice, but not so many that questions and evaluation become superficial. A small pre-qualified group usually produces better discussion than an open process with weak fit.
May an agency challenge the RFP?
Yes. It should identify which requirement it would solve differently, the assumption behind the alternative and how cost, risk and operations change. An unexplained deviation is not innovation.
Official sources
Primary sources for platform capabilities and commercial assumptions. Prices and editions can change.
Continue deciding
Related decisions
Sharpen the RFP before procurement starts
We review the target state, system inventory, acceptance criteria and scoring model before they become a project proposal.
Explore Shopify consulting