Evaluate how they frame the problem
A strong partner should ask about the business, users and operational constraints before committing to a visual solution or technology stack.
Listen for specific questions
Useful discovery explores audiences, decisions, content ownership, integrations, approval and what is known versus assumed.
Be cautious with guaranteed outcomes
Rankings, sales and growth depend on conditions outside a website project. Credible teams separate intended benefit from measured result.
Make the working relationship visible
The proposal should explain who you will work with, how decisions are recorded and where approval is expected.
Understand communication structure
Know whether you have direct access to the people making strategic, design and technical decisions.
Ask how changes are handled
A clear method for scope decisions protects both sides and makes trade-offs deliberate.
Look for complete quality thinking
A portfolio view is useful, but the partner should also explain performance, accessibility, content, security and maintainability in practical terms.
Request validation boundaries
Ask which devices, browsers, pages and journeys will actually be tested and how missing evidence will be reported.
Clarify ownership after launch
Confirm access, documentation, source ownership, support conditions and how future providers can work with the site.
Read the proposal as an operating plan
A good proposal connects the problem, recommended scope, responsibilities, sequence and acceptance method. It should show what the partner needs from your team and what happens when an assumption proves wrong. A long feature list is not a substitute for explaining how the work will move from uncertainty to approved, testable decisions.
Check inclusions and exclusions
Look for discovery, content, translation, design, development, migration, integration, testing, launch and support. Explicit exclusions are useful because they reveal where another supplier or your internal team must contribute.
Understand commercial change control
Ask how new information, delayed inputs and added requirements affect price and timing. A fair process records the option, consequence and approval before work begins rather than using ambiguity as leverage at the end.
Evaluate evidence with context
Portfolio pieces show craft, but they rarely reveal the starting conditions, the partner’s exact contribution or the constraints of the project. Ask for a walkthrough of decisions and trade-offs. The most relevant evidence may be a clear explanation of a difficult migration or editorial system, not the project with the closest colour palette.
Distinguish work from outcomes
A partner can demonstrate research, design, engineering and validation they performed. Commercial growth, rankings or conversion changes require measured data and broader context. Be wary when attractive results are presented without a stated source or boundary.
Use a small paid exercise when needed
For a complex or high-risk engagement, a focused discovery, audit or prototype can test collaboration before the full build. Define the question, deliverable and ownership so the exercise produces reusable value rather than unpaid speculative design.
Plan for disagreement and continuity
Healthy projects contain trade-offs. The important question is how the team exposes them, records decisions and escalates a genuine impasse. The relationship should also remain workable if people change roles or you later choose another provider. Clear records and portable access are signs of professional confidence, not a lack of loyalty.
Ask how risks are communicated
A partner should explain technical or delivery concerns early, give options and state what is not yet verified. Constant reassurance can be more dangerous than a timely, well-supported objection.
Define a practical handover
Confirm source and content ownership, repository and hosting access, design files, licences, account administration, documentation and support end dates. Credentials should be transferred securely and no essential system should depend on a single personal account.
Questions readers ask
Style matters, but ask how the work was framed, what the team actually delivered and which constraints shaped it. Process, communication, technical judgement and the ability to work with your content and organisation are equally important.
There is no universal number. A short list of credible, appropriately sized teams usually allows a meaningful comparison without turning the process into unpaid speculative work. Give each one the same core context and enough access to ask clarifying questions.
Not necessarily; a focused team or narrower scope may be efficient. The risk appears when a low total depends on hidden exclusions, unrealistic client effort, weak validation or inaccessible ownership. Compare the underlying commitments and assumptions before judging value.
Administration support can be useful, but the organisation should retain appropriate ownership and recovery access for essential accounts. Define roles and secure credential handling so a staffing or supplier change does not interrupt ordinary operation. Review that access at handover and whenever responsibilities change.