Start with the business problem, not the framework
A useful first conversation should focus on the people using the system, the work they need to complete, what is difficult today, and which outcomes matter to the business. Technology matters, but choosing a supplier only because a framework appears on its website can hide whether the team understands the actual problem.
For eCommerce and business-system projects, explain the journey around the software as well as the screen you want changed. A checkout issue may involve payment services, product information, stock, order handling, or fulfilment. A portal may depend on customer records or an internal approval process. The wider context helps a development team identify dependencies before they become delivery surprises.
Ask how the team will understand an existing system
When the project involves software already in use, ask how the supplier will learn the current behaviour before changing it. Existing stores and applications often contain business rules, integrations, extensions, and operational workarounds that are not obvious from a short brief.
A credible approach should include enough discovery to understand the current environment, but discovery should lead to decisions and delivery rather than becoming an open-ended consulting exercise. You should be able to see how findings will be converted into an agreed scope or next step.
Make responsibilities and boundaries explicit
Ask what the supplier will deliver, what your team needs to provide, and where third parties are involved. If a project depends on an ERP, payment service, hosting provider, fulfilment platform, or another development team, those dependencies should be visible before implementation begins.
It is equally useful to understand what is outside the initial scope. Clear boundaries make it easier to handle new requirements without pretending that every request was included from the beginning.
Discuss testing, releases, and change control
For software that already supports customers or business operations, ask how changes are verified before release. The right answer depends on the project, but there should be a clear way to check the important customer journeys and integration paths affected by the work.
Also ask how new findings are handled. Software projects uncover information as work progresses. A healthy process should distinguish between correcting the agreed implementation and introducing genuinely new scope.
Decide what happens after delivery
A project is easier to evaluate when you know who will own the software after the initial delivery. Ask whether the same team can provide ongoing engineering support, how future changes are raised, and which responsibilities remain with your internal team or other suppliers.
The goal is not to demand a particular support model from every company. It is to avoid discovering after launch that nobody has clearly agreed who will investigate the next problem or implement the next required change.
Look for evidence that matches the risk in your project
A long client list is less useful than evidence relevant to the work you are considering. For a Magento project, look for experience with live commerce, upgrades, extensions, and connected services. For an integration project, look for signs that the team thinks about data ownership, failure handling, and operational consequences rather than only API endpoints.
Case studies do not need dramatic percentage claims to be useful. A clear description of the problem, the supplier’s role, the systems involved, and the work delivered can tell you more than a marketing result with no baseline or source. Ask follow-up questions where the published example is intentionally limited by confidentiality.
Compare the quality of the proposed approach, not only the price
Two proposals can describe the same headline requirement while making very different assumptions about discovery, testing, integrations, deployment, and support. Compare what each team appears to understand and what it expects to verify before committing to the implementation.
A lower initial estimate is not automatically better if important dependencies have simply been ignored. Equally, a larger proposal is not automatically more thorough. The useful question is whether the proposed work is proportionate to the business risk and whether you can understand why each major activity is there.
A strong partner should be able to explain trade-offs in plain language. You should leave the discussion with a clearer understanding of the problem and the next decision, not a larger collection of technical terms.