he cheapest proposal can be the most expensive if it omits content, migration, testing, ownership or the systems the product depends on. The largest agency can still assign the work to people you never met. Choosing well means comparing how each supplier understands the problem, contains risk and leaves the business in control—not counting how many pages appear in the pitch deck.
A good supplier should be able to restate the business problem, the users affected and the result that would make the project worthwhile. Be cautious when the proposed solution arrives before questions about the current workflow, evidence, constraints and alternatives. Technical confidence includes knowing when a custom build is unnecessary.
- What is included, excluded and assumed?
- Who will actually design, build and approve the work?
- What must the client provide, and by when?
- How are changes estimated and authorised?
- Which browsers, devices, accessibility needs and failure paths will be tested?
- Who owns the source, accounts, data and reusable third-party licences?
- What happens at launch, during warranty and after support ends?
- What evidence can be verified, and which work is only a concept?
Normalise the proposals. One may include copy migration, analytics, redirects, accessibility testing and deployment while another prices only design and implementation. Ask what would have to be purchased later to reach the same live result. Payment milestones should correspond to understandable progress, and the acceptance process should say how both sides know a stage is complete.
Credible suppliers distinguish completed client work from concepts, explain tradeoffs, identify uncertainties and avoid guaranteed search rankings or App Store approval. They are clear about where work happens and who has access. They should be comfortable putting ownership, security responsibilities, third-party costs and handover into writing.
- A large non-refundable payment before scope, milestones or acceptance are clear.
- The agency keeps the domain, hosting or repository under an account the client cannot control.
- The portfolio makes results or client relationships difficult to verify.
- The proposal promises every feature but identifies no dependencies or exclusions.
- There is no staging, testing, rollback, backup or launch plan.
- Support is described as 'included' without a period, response model or boundary.
- The supplier avoids explaining what happens if the relationship ends.
Ask to meet the people responsible for delivery and see how decisions, feedback and problems will be documented. A strong working model can be a small senior studio or a larger specialist team; what matters is that communication paths and accountability match the project's complexity. References and case studies become more valuable when you ask about the difficult part of the project, not just whether the client was happy.
- Who will actually do the work, and which parts are subcontracted?
- What evidence will discovery produce before full implementation begins?
- How do you test accessibility, security, performance and search fundamentals?
- Who owns the domain, source repository, hosting, analytics and design files during the build?
- Which outcome triggers each invoice, and how is acceptance recorded?
- What is excluded, and how are scope changes priced?
- How does another supplier take over if priorities or relationships change?
- What happens in the first 90 days after launch?
Ask each finalist to walk through one comparable project from initial uncertainty to measurable result, including a mistake or changed assumption. Process becomes credible when the team can show decisions, trade-offs and evidence—not only polished screenshots.
Choosetheteamwhosewayofreducinguncertaintyisclearest,nottheteamthatsoundsmostcertainbeforediscovery.