Choosing a software development company in Quebec: compare three proposals

A request for proposal should not already contain all the technical answers. It should describe what is happening today, what needs to change, and the constraints the project must respect. For a Quebec distributor, this could be: receiving an order, confirming stock, reserving items, and transmitting the information to accounting, with a designated person responsible for each exception.

Provide a small common dossier: user descriptions, main workflow, systems to connect, anonymized data examples, and availability constraints. Indicate what remains unknown. A serious supplier can propose to resolve these unknowns during a discovery phase, rather than burying a contingency in the price.

Then request a response in the same order: understanding of the problem, included scope, assumptions, exclusions, deliverables, acceptance criteria, team, schedule, dependencies, and maintenance. This format reduces space for commercial presentations that do not address the constraints of your organization.

This grid is an editorial method, not a supplier certification. It must be adapted to your context. An application used during office hours does not require the same commitments as a system that blocks shipments during a breakdown.

The development team must be able to explain how it maintains the system after the first delivery. A prototype demonstration is useful; it does not prove data restoration or the ability to resume by another team.

Define your priorities before opening proposals. Use the same zero-to-five scale for all criteria, as in the weighted grid below. A statement alone deserves fewer points than a demonstration on your scenario accompanied by a written responsibility. Then weight it according to the real risk of the project.

Keep a comment next to each score. "Three points for the migration" does not help management decide; "a data copy repetition is included, with control of amounts and testing of customer-order relationships" explains what was evaluated. Disagreements between IT, operations, and finance then become discussable.

A high total score should not erase an eliminatory criterion. If you need to export all data and the proposal does not provide any usable output, the gap must be resolved before signing. Similarly, the absence of a person available to validate processes with you can delay all three suppliers.

Plan a meeting focused on a concrete workflow. For example: an order contains an item that has become unavailable, the representative modifies the quantity, and accounting has already received a first version. Ask who owns the information, how a modification is propagated, and how an employee understands the final state.

Observe how the teams ask questions. Are they trying to understand the process or do they immediately propose a tool? Can they explain a compromise without jargon? Do they recognize the risks and the need for a trial? This meeting informs you about daily collaboration, which matters as much as the technology stack.

For accessibility, W3C resources recommend integrating the approach into project planning and responsibilities. In your request, translate this objective into keyboard-navigable paths, understandable messages, and verification with the relevant profiles. Do not assume that a modern interface is automatically accessible.

The initial cost is part of the total cost. Also compare environments, third-party services, licenses, support, training, fixes, and updates. Ask what happens if an external service changes its interface or if a key person leaves the team. Distinguish between fixed costs, usage costs, and those that depend on a scope change.

Fictional illustration: a cheaper proposal may exclude data cleaning and consider each rework as additional work. A higher proposal may cover one migration repetition and two acceptance workshops. This does not automatically make the second one better; it reveals that the prices do not cover the same delivery.

Do not build a fictitious return from an announced saving. First, measure the current time, the volume involved, and exceptions. An improvement on a rare path may be less of a priority than a small change used daily by the entire team.

Ask where the code, data, environments, and access are located. Clarify the accounts belonging to your company and the services operated by the provider. The handover must cover deployment, backups, dependencies, known incidents, and the steps to get the system running again.

OWASP documents especially the risks of authorization and resource access in APIs. For an integrated project, ask what rights each connection has, how they are limited, and how sensitive events are reviewed. This discussion must lead to observable controls, not a promise of absolute security.

Finally, compare the decision to build with other options. Our framework for choosing a custom application or SaaS helps to determine what truly deserves to be developed. The best partner may be the one who reduces the initial scope to a first useful delivery.

Here is a working model proposed by Daillac, to be adapted to the project. The weights below are an example of a decision, not a ranking of agencies. Assign a score from zero to five: zero means no response; one, a statement; three, a partial demonstration; five, proof on your scenario and written responsibility. The contribution to the total is the weight multiplied by the score, divided by five. Have the proposals scored separately by operations and IT before discussing discrepancies.

A score does not compensate for a critical blockage. If data recovery is essential and excluded from the proposal, request an addition before scoring. Keep a comment column in your own sheet: "evidence received", "assumption" or "open question". An empty cell remains an unknown, rather than a default average score.

Let’s imagine a Quebec distributor who wants to replace its order tracking with an internal application. A proposes CAD 40,000 with the screens, but without migration; B proposes CAD 55,000 with documented recovery; C proposes CAD 48,000 with a connector whose exceptions are yet to be specified. These amounts are entirely fictitious and do not constitute a Daillac benchmark. The scenario includes creating an order, a modification after validation, and the recovery of five years of history.

With the criteria in the order of the grid, A receives 4, 2, 3, 4, 2, 3; B receives 4, 4, 4, 3, 4, 4; C receives 4, 3, 3, 4, 3, 3. The totals are respectively 62, 77, and 68 out of 100. B gets the best temporary total, but the choice still depends on exclusions and the full cost. A can improve their proposal by quantifying the migration; C must show recovery after connector failure. Therefore, a clarified version of each offer is also compared.

Before making the decision, ask each team for the same additional costs: migration, licenses, operations over two years, and out-of-scope changes. Do not add internal estimates from only one proposal: apply the same method to all three. The expected result of the meeting is a list of gaps to resolve and a justified decision, not an average that gives a false impression of precision.

W3C WAI — Planning and managing accessibility · OWASP — API Security Top 10, 2023 edition. Sources consulted on October 1, 2026; the grids and decision examples are an editorial analysis by Daillac.