How to evaluate a web development agency before you sign

Evaluating a development agency comes down to three tests: can they show you working software they built, will they tell you exactly how you will see progress week to week, and do the contract terms leave you owning everything at the end. Decks, logo walls and awards pages answer none of those. What follows is the set of questions, the proposal checklist and the handover clauses to use before you sign anything.

Run the evaluation in a fixed order

Most selection processes go wrong because they start with price and end with capability. Reverse it. A price is only meaningful once you know what the work actually is, and you only know that after a proper discovery conversation. Run the same sequence with every shortlisted firm so you are comparing like with like.

1. Write a one page problem statement: who the users are, what they need to do, what already exists, and what a successful first release looks like.
2. Send it to three or four agencies. Not ten. A long list produces generic responses, because nobody invests real thought in a lottery.
3. Hold a working session with each, sixty to ninety minutes, with the people who would actually do the work in the room.
4. Ask for a proposal that responds to what surfaced in that session, not a template with your logo on the cover.
5. Take references after the proposals arrive, so you can ask reference clients about the specific promises being made to you.
6. Compare, then negotiate terms. Ownership and handover language is far easier to fix before a number is agreed than after.

The questions that reveal real capability

Capability questions have one thing in common: a firm that has done the work answers with specifics, and a firm that has not answers with adjectives. Listen for named systems, named trade-offs and named mistakes.

• Show me something you built that is live right now, and walk me through a part of it that was difficult. The difficulty is the point. Anyone can demo a happy path.
• Who exactly will write this code, and what else are they on? You want names, roles and honest availability. If the answer is a resourcing abstraction, the people you meet are not the people you get.
• How will I see progress between now and launch? A weekly working demo is the only answer that removes the guesswork. A status report describes progress; a demo proves it.
• What would you cut from my brief, and why? A studio that will not push back during a sales conversation certainly will not push back six weeks in, when the budget is tight and the deadline is close.
• How do you handle accessibility, and to what standard? WCAG 2.2 AA should be a normal part of the build, not a line item you buy separately after launch.
• What happens when something breaks at two in the morning? Ask about logging, alerting, on-call and rollback. Vague answers here predict a rough first month in production.
• Tell me about a project that went badly. Everyone has one. The useful signal is whether they can describe the cause without blaming the client.

A demo you can click beats a deck you can only nod at.

What a good proposal actually contains

A proposal is a working document, not a brochure. Yours should be readable by your finance lead and your future developer with equal ease. Check it against this list.

• A restatement of your problem in their words, so you can tell whether they listened.
• Scope split into what is included and what is explicitly excluded. The exclusions matter more. Ambiguity always resolves in favour of whoever wrote the document.
• Assumptions written down: content supplied by you, third party integrations, access to systems, approval turnaround. Each one is a future delay if it goes unstated.
• The architecture in plain language, including the stack and the hosting, and why those choices suit your case rather than their habits.
• A named team with roles, plus the one person accountable to you when something goes wrong.
• A delivery rhythm: what you see each week, how your feedback is captured, and how long you have to give it.
• A change process with a defined path for new requests, so a change becomes a decision rather than an argument.
• Testing, accessibility and performance commitments written as acceptance criteria, not aspirations.
• Handover and support after launch, including the training you get and what happens if you take the work in house.

If a proposal is mostly timeline graphics and team photos, ask for a version that answers the list above. How a firm responds to that request is itself a data point. Our own approach to scoping and weekly demos is set out under how we work, and the same structure applies whether the engagement is a marketing site or a full-stack build.

Ownership and handover terms to insist on

This is where a selection decision quietly becomes a commitment that outlasts the build. Ownership is not one clause, it is five, and each has to be checked separately.

• Intellectual property. Code, designs and content transfer to you. Watch for language that grants you a licence to use software the agency continues to own.
• Accounts in your name. Domain registrar, DNS, hosting, cloud, analytics, ad accounts and app store listings should be registered to your organisation, with the agency added as a user. Reversing this later is tedious and occasionally impossible.
• Repository access from day one. Not a zip file at the end. Continuous visibility of the code is the cheapest insurance available to you.
• Data portability. You can export your content and your database in a documented, usable format without asking permission.
• A handover package defined in the contract: repository, environment configuration, credentials in a password manager, a deployment runbook and a short recorded walkthrough.

One test cuts through all of it. Ask directly: if we part ways in twelve months, what exactly do we walk away with, and how long would it take another team to run this? A confident firm answers in a minute. A firm that depends on lock-in starts explaining why you would never want to leave.

Warning signs, and what to ask instead

Most bad engagements were visible during the sales process. The signals below are common, and each one has a question that either resolves it or confirms it.

Reference checks that are worth making

Agencies supply references who will be positive, so treat the call as a source of texture rather than a verdict. Ask about process, not satisfaction. Useful prompts: what surprised you during the build; what did you end up doing yourself that you had not planned for; how were disagreements handled; what happened the first time a deadline was at risk; how quickly did they reply when something broke after launch; would the same team be available to you again.

Two further moves are worth the effort. Ask for a reference from a project that has ended, not only from a current client, because how a firm behaves on the way out tells you what handover really looks like. And inspect the agency's public work directly rather than through a case study: open the sites on a phone, run a page through a performance tool, tab through a form with the keyboard. Ten minutes of that beats an hour of testimonials. If you want to see how we present our own, our project examples are there to be poked at the same way.

How OlDevs approaches this, and what to do next

We have been building web, mobile and AI products from Vancouver since 2014, and we run engagements so that the questions above are easy to answer. One accountable team, so the people who scope the work are the people who build it. A working demo every week, so progress is something you see rather than something you are told about. Clients own all code, designs, accounts and IP, with handover assumed from the start rather than negotiated at the end. Accessibility to WCAG 2.2 AA is part of the build, and we work bilingually in English and French where that is needed. Clients outside Vancouver get video calls in their own time zone, and on-site visits when the work calls for it.

Use this guide on whoever you shortlist, including us. If you would like a scoped, plain-language proposal written against your problem statement, request a quote and we will reply within one business day.