RFI, RFP or RFQ: how to choose a development partner for an online store

RFI, RFP or RFQ: the choice should depend not on the size of your budget, but on what you do not yet know about your future online store. If you are unsure what the market can offer, you need information. If the outcome is defined but the way to achieve it is still open, you need proposed solutions. If the scope and terms are already agreed, you can request comparable prices.

A common mistake is to ask several teams to ‘quote for a store with ERP integration’ and compare the totals. One team includes only order transfers; another also includes stock levels, returns and recovery from failures. The price difference then reflects different assumptions about scope, not differences in the developers’ efficiency. The right request should make those assumptions visible before a contract is signed.

1. Start with the uncertainty, not the document’s name

Together with your heads of sales and marketing and the person responsible for your business management system, write down what the store needs to change: give dealers personalised prices, eliminate manual order transfers or support multiple warehouses. Separate known facts, preferences and unanswered questions.

For example, to display stock availability, you need to establish which system controls stock reservations, how up to date the data needs to be and what the customer sees during an outage. Until you know this, a fixed estimate creates a false sense of precision. Investigation needs to come first.

2. How RFI, RFP and RFQ differ

RFI stands for Request for Information; RFP, Request for Proposal; and RFQ, Request for Quotation. The New Zealand Government Procurement guidance relates this distinction to the purpose of the procurement: exploring the market, obtaining an approach to achieving an outcome or pricing a clearly defined supply. What follows is a practical adaptation for Ukrainian private businesses, not a mandatory foreign procedure.

This is not a mandatory sequence of three competitive selection processes. If you understand the market and the task, go straight to an RFP. If all material terms are already defined, use an RFQ. Even a large budget does not automatically make a request for proposals necessary, and a small budget does not remove technical uncertainty.

3. RFI: obtain the knowledge you lack as a client

A short RFI is appropriate when you do not know whether an off-the-shelf solution will suffice or custom development is needed. Describe your sales model, buyer roles, existing systems, the state of your catalogue and launch constraints. Ask teams to explain possible approaches, their trade-offs, the access they would need and what cannot be estimated without investigation. An indicative budget can be discussed, but it does not replace a subsequent cost estimate.

Ask about boundaries, not the number of features

Instead of ‘Can you integrate our ERP?’, ask: ‘What data and documentation do you need to estimate the exchange of prices, stock levels and orders?’ Instead of ‘Does the system scale?’, ask: ‘Which load parameters need to be measured before choosing the architecture?’ A useful answer identifies conditions and unknowns rather than simply agreeing to every wish.

The outcome of an RFI is a refined brief, alternatives and a list of checks. Make it clear that this is research, not the selection of a winner. Detailed solution design or a prototype requires a separately agreed scope, rather than being provided free of charge as part of the response.

4. RFP: make different solutions comparable

In an RFP, provide a shared context but leave room for well-reasoned alternatives. Include goals, the scope of the initial launch, key scenarios, a list of systems, data migration requirements and acceptance criteria. Distinguish must-haves from nice-to-haves. If the technology has not been chosen, ask teams to explain their choice; if it has, state the actual constraint rather than merely naming a platform.

One response format for every team

Prepare a matrix covering the requirement ID, implementation approach, what is included in the price, dependencies on the client, exclusions and evidence of delivery. For each feature, the response should distinguish between an out-of-the-box capability, configuration, custom development and an external service. Saying ‘supported’ without these details conceals future costs.

Ask for a price breakdown covering analysis, design, development, integrations, migration, testing, launch and support. Separate the base scope from optional items. For recurring costs, agree on a common comparison period, currency, tax treatment and level of service usage.

Before receiving responses, define the evaluation criteria: coverage of critical scenarios, quality of evidence, how well integrations can be managed, the team, support and total cost. Choose weightings to suit your own risks rather than using a universal formula. Share participants’ questions and general clarifications to the requirements with everyone in the same wording, without disclosing other participants’ commercial information.

Check separately who will actually do the work, how changes are approved and who is responsible for third-party contractors. Information about GL.ua (Glyanets), like any other candidate’s corporate page, provides context but does not replace checking the specific team and its proposal.

5. RFQ: request prices only for a clearly defined scope

An RFQ requires the same outcome, specification, test data and acceptance rules for everyone. If each team defines the discount logic or migration scope itself, the prices will not be comparable.

Specify the version of the specification. Ask teams to state how long the price remains valid, exclusions, payment terms, dependencies on access and the procedure for changing the scope. Clarify whether defect fixes, deployment, documentation and handover are included.

If participants come back with questions instead of a price, clarify the scope or commission a separate analysis of the unknown component. An RFQ can cover a defined part of the work rather than the entire store.

6. Test a high-risk integration before the main contract

A demonstration of a finished store shows the interface, but does not prove that data exchange with your business management system will be reliable. For the highest-risk scenario, agree on a limited technical assessment: a prototype, a data exchange test or a review of the actual documentation. This is a separate piece of work with a defined deliverable, access requirements and completion criteria, not a demand to build part of the product for free.

1. Choose a critical flow: product and price data from the business management system, orders from the store, payment confirmation and status changes. Identify the owner of each data type.
2. Provide a test environment, documentation for the API—the interface for exchanging data between systems—and anonymised examples. Check permissions and request rate limits.
3. Record the expected outcome for normal processing, failure, delay and a repeated message. Define how to reconcile records on both sides.
4. Reproduce a connection failure and a retry. Check whether duplicate orders or stock reservations were created and how the operator was notified of the error.
5. Obtain a test log, a list of limitations and a conclusion: confirmed, a change of approach is needed or there is insufficient data. Update the estimate and acceptance criteria.

Protection against executing the same operation more than once is called idempotency. For example, Stripe’s documentation on repeated API requests describes using a key to retry an operation safely. This is an example of a mechanism, not proof that your ERP has the same protection: the behaviour of the specific integration must be tested separately.

Security also requires evidence

CISA’s Software Acquisition Guide addresses the assessment of supplier practices throughout the software lifecycle. For a store, the practical questions concern access, dependencies, updates and vulnerability response. This is a useful framework for discussion, not a requirement to follow US government procedures.

Instead of saying ‘the website must be secure’, agree on who will check role permissions, protection of administrative access and restoration from a backup. OWASP ASVS can serve as the basis for specific verification requirements. State the version, applicable requirements and evidence; a link to the standard alone does not demonstrate compliance.

7. Calculate timelines, costs and the price of unknowns

The schedule depends on more than the developers. It is affected by catalogue readiness, design approvals, ERP access, the payment provider’s involvement, data cleansing and the availability of the client’s staff. Require a plan showing dependencies and responsibilities: what can be done in parallel, what blocks the next stage and when the estimate will be reassessed. An overall date without these conditions does little to help manage the launch.

Compare not only the cost of building the store, but also the cost of owning it. Show business analysis, solution planning, design, development, data exchange, migration, checks and training separately in the calculation. Recurring costs include infrastructure, paid services, monitoring, updates and support. Find out which charges depend on orders, users or data volumes, and who signs the contracts with those services.

For work with unknown requirements, ask for an explanation rather than a hidden markup: what exactly is unknown, how it can be established and when the estimate will change. A fixed price does not resolve unclear requirements, and hourly billing does not remove the need for budget control. Both models need boundaries, reporting and a change approval procedure. Review commercial and legal terms with the relevant specialists; this article is not legal advice.

8. Choose based on verified results, not promises

Before making the final decision, return to the requirements matrix. An unacceptable risk in a critical integration should not be offset by a more attractive design or a lower total. At the same time, a prototype does not prove that the entire store is ready for peak load: it only resolves a specific unknown. The remaining scenarios will need their own checks during development and launch.

Record agreed clarifications in the scope of work rather than leaving them in correspondence. Define acceptance criteria, who is responsible for data and access, support arrangements and the rules for handing over code, documentation and configuration. Do not give participants production passwords or complete customer databases for the sake of an estimate. Use limited access and anonymised data for the initial assessment.

A good selection outcome is not the longest RFP, but a proposal that makes the deliverable scope, verified capabilities and remaining risks clear. If you are planning a new store or a migration, discuss online store development with GL.ua: share your business scenarios, list of systems and open questions, so the conversation starts with the actual task rather than incomparable prices.