Agencies should evaluate a website development partner by looking for evidence of how the company actually delivers work, not by counting portfolio items, technology logos or positive reviews.
The useful questions are practical: who will work on the project, how risks are handled, what QA happens before agency review, how estimates are built, what happens when scope changes and how the partner behaves around the agency’s client relationship. Most vendors can describe themselves as experienced, responsive and reliable. The evaluation starts when those claims are tested.
Define what the partner needs to own before comparing companies
A development company cannot be a good partner in the abstract. It can only be a good fit for a particular delivery requirement.
Before comparing vendors, define what is actually being transferred. Is the partner expected to build complete websites from approved designs, provide specialist backend work, handle CMS implementation, support an internal development team or own most of the technical delivery?
The agency should also separate mandatory requirements from preferences. A particular CMS may be essential because of recurring client demand. Experience with another framework may be useful but irrelevant to the work likely to be assigned.
Project Management Institute guidance on vendor selection follows the same basic sequence: define requirements, establish criteria, evaluate suppliers and then negotiate. The principle is old, but still useful. If evaluation criteria change every time a vendor gives a strong sales presentation, the comparison stops being meaningful.
Verify delivery evidence, not just portfolio quality
A polished portfolio proves that a company was involved in good-looking projects. It does not necessarily show what that company actually did.
For relevant examples, ask what the development partner owned. Did it receive finished designs and build the site? Did another company handle architecture? Was the partner responsible for QA, integrations or migration? What went wrong during the project and how was it handled?
Live websites are useful because they allow at least part of the work to be inspected outside a curated case-study page. References can add another layer, particularly when the reference comes from an agency with a similar delivery model.
The point is not to interrogate every case study. It is to understand whether the evidence resembles the work the agency plans to assign.
A technically impressive project may establish capability while telling you almost nothing about estimation quality, communication or delivery discipline. Those need separate evidence.
Find out how the work will actually be delivered
This is where company-level claims need to become concrete.
Ask who will work on the projects, who manages them and who makes technical decisions. The people on a sales call may not be the people handling delivery, which is not necessarily a problem, but the agency should know where responsibility moves after the contract is signed.
Subcontracting deserves the same treatment. It is not automatically a warning sign. The relevant issue is whether the arrangement is transparent and whether accountability remains clear.
The agency should also understand what happens when the assigned developer becomes unavailable. Is another developer able to take over? Is project knowledge documented? Does the provider have genuine backup capacity or does the same person remain the single point of failure?
Communication needs similar scrutiny. Asking whether a company is “responsive” tells you very little. Ask how risks are escalated, who reports a likely delay, what information accompanies that warning and how decisions are recorded.
“I would ask them to describe a normal project almost step by step. Not every tiny detail, but who receives the work, how it is estimated, when developers get involved, how QA is done and who gives the final go-ahead before the agency sees it. A good process is usually quite easy to explain.”
Dmytro Mashchenko, COO of GetDevDone
Test technical judgment, QA and security proportionately
Technology lists are weak evidence of technical judgment. A company can claim WordPress, Shopify, React or Laravel experience without showing how well it handles decisions around those technologies.
A better test is to give the partner a representative project situation and ask how it would approach it. What information would it need before estimating? Where does it see technical risk? Which assumptions would it want confirmed? What alternatives would it consider?
The quality of the reasoning matters more than whether the answer uses the same tools the agency expected.
QA should also be examined one level deeper than “Do you have QA?”
Ask who reviews work before it reaches the agency, what is checked and what requirements that review uses. If the answer is essentially that the client or agency reports problems after delivery, then the agency may be acting as the partner’s QA layer.
Security evaluation should match the project. A brochure website and an application handling sensitive customer data do not need identical due diligence.
For higher-risk work, supplier assessment can include access controls, development environments, credential handling, deployment practices and how security is addressed during development rather than only before launch. NCSC supplier-assurance guidance and NIST’s Secure Software Development Framework are useful references for this type of evaluation without turning every agency project into an enterprise audit.
Sources: NCSC, Supplier Assurance Questions and NIST, Secure Software Development Framework
Examine estimates, scope changes and commercial terms as delivery evidence
An estimate is useful for more than comparing price and deadline. It also shows how the partner thinks about the work.
Look at what sits behind the number. Are assumptions stated? Are dependencies clear? Does the estimate identify inputs required from the agency? Are unclear requirements flagged or simply priced as if they were settled?
The change process matters just as much. Website projects change. A mature partner should be able to explain what happens when new functionality appears, an integration behaves differently than expected or an approved design changes during development.
Pricing model alone proves little. Fixed price does not automatically mean better scoping, while hourly billing does not mean poor estimation. The commercial model mainly changes how financial risk is distributed.
Contracts should also make ownership and exit conditions clear. Confirm who owns the code and deliverables, what repository access the agency receives, whether third-party licenses create restrictions and what happens if the relationship ends.
UK government digital procurement guidance makes supplier lock-in and intellectual-property arrangements explicit procurement concerns. Agency projects are smaller, but the principle translates well: a development relationship should not become difficult to leave simply because access and ownership were never clarified.
Source: UK Government, Digital, Data and Technology Playbook
Agencies need to evaluate the client-relationship layer too
A generic buyer choosing a company to build its own website does not have an end client sitting behind the project. Agencies do.
That changes the evaluation.
A development partner may receive client credentials, confidential designs, pricing information, staging access and project documentation. If the work is white-label or behind the scenes, the agency should define whether the partner can contact the client directly, under whose identity and with whose approval.
Portfolio attribution belongs here as well. Some agencies are happy for development partners to show completed work publicly. Others are not. The agreement should reflect the actual relationship rather than leaving everyone to assume.
Scope authority is another useful detail. A developer discussing a feature directly with the client’s marketing manager should not necessarily be able to turn that conversation into additional project work.
An excellent development company can still be the wrong agency partner if its preferred operating model conflicts with the way the agency manages its client relationships.
Validate the pitch before committing important client work
References are most useful when the questions go beyond “Were you happy?”
Ask how accurate estimates were, whether deadlines slipped, how problems were communicated, how many corrections were typically needed and how scope changes were handled. It is also worth asking what the previous client would change if starting the relationship again.
For a partner expected to handle substantial or recurring work, a smaller paid project or discovery engagement can provide stronger evidence than another sales call.
A pilot can reveal how the company communicates, how it deals with ambiguity, whether estimates contain useful assumptions, how QA works and whether the people presented during sales are actually available during delivery.
Not every one-off website needs a trial engagement. The more client work the agency expects to put through the relationship, the more valuable this kind of validation becomes.
Use the same evaluation criteria across shortlisted partners. A good salesperson, attractive portfolio or unusually low estimate should not quietly change the rules halfway through the decision.
Make the decision on evidence, not the number of boxes checked
The best website development partner is not the company that can answer “yes” to the most questions.
Some weaknesses may be perfectly manageable. An agency with strong internal technical leadership may not need extensive external project management. Another agency may care far more about reliable QA, client confidentiality or backup capacity.
What matters is knowing which claims have actually been verified, which risks remain and which responsibilities the agency will still need to carry itself.
The strongest partner is the one whose relevant capabilities, delivery process and limitations are reasonably clear before those assumptions are tested on a real client project.