How to Choose a Digital Agency: 12 Questions That Reveal Everything

Updated August 24, 2026

Portfolios all look the same. These twelve questions surface how an agency actually works — and the answers that should end the conversation.

Every agency site shows beautiful work, claims a rigorous process and features glowing testimonials. None of that predicts what happens when your project hits its first genuine complication — which it will, in week three. These questions do.

On the work itself

1. Which parts of the portfolio piece you just showed me did your team actually build, and which were subcontracted? Agencies presenting partner work as their own are common, and the answer is easy to verify with a reference call.
2. Show me a project that went badly and what you changed afterwards. An agency with no failures either has not shipped enough or is not being honest with you.
3. Who specifically will work on this, and what else are they on during that period? "Our team" is not an answer. Named people with named availability is.
4. What happens if that person leaves mid-project? The answer should involve documentation and shared knowledge, not reassurance.

On process and control

1. What do I see, and when? Weekly working software beats monthly status decks. If you cannot click something by week three, you have no early warning system.
2. How do you handle a scope change I request in week five? A mature answer describes a written change process with cost and schedule impact — not "we'll figure it out", which reliably becomes an invoice dispute.
3. What is the definition of done for a feature? Look for testing, review and acceptance criteria rather than "it works on my machine".
4. Which decisions do you need from me, and by when? An agency that has thought about your critical path will hand you a list of decision deadlines.

On ownership and exit

1. Do I own the source code, the designs and the accounts outright, in writing? Anything less is a hostage arrangement dressed as a service agreement.
2. Where does the code live, and can I have access from day one? The repository should be in your organization, with the agency invited to it — not the reverse.
3. If I hire another team next year, what would you hand over? The honest answer is a repository, documented environment setup, credentials and an architecture note. Anything vaguer means an expensive rediscovery phase.
4. What does support look like after launch — response times, cost, and who is on call?

How to read the answers

Specificity is the signal. Good agencies answer with numbers, artefacts and named constraints; weaker ones answer with adjectives. Notice also whether they ask you questions back. An agency that spends the first meeting understanding your commercial model rather than presenting its own capabilities is one that will build the right thing.

On money, before anyone signs

1. What is explicitly excluded from this price? The exclusions list tells you more about a proposal than the inclusions list does, and it explains most of why three quotes for the same brief differ so widely.
2. How is payment staged, and what does each stage require from me? Milestones tied to delivered, working software protect both sides. A schedule tied only to dates protects one.
3. What is the rate for work outside the scope, and who authorises it? Agree this before you need it, not during the week you need it.
4. Which third-party costs will I be billed for, and are they in your name or mine? Hosting, licences and API usage should sit on your accounts, not resold at a margin you cannot see.

What to check without asking them

• Open their own site on a phone, on mobile data. An agency that sells performance and ships a slow site is telling you where its standards actually are.
• Call one reference they did not choose. Ask the portfolio question in reverse: which parts did the agency build, and what happened when something went wrong.
• Look for specifics in their case studies. Numbers, constraints and trade-offs indicate real involvement; adjectives and mood boards indicate a slide.
• Check who signs the contract against who will do the work. If the entity is a holding company and the work is subcontracted abroad, that is not disqualifying, but you should know it before you sign, not after.

Answers that should end the conversation

• Any hesitation on code and data ownership. There is no legitimate version of a partial answer here, which is why we put the repository in your organisation at the start rather than at the end.
• A guaranteed position on Google. Nobody controls that, and the offer tells you what else they are willing to claim.
• A price that expires at the end of the week. Urgency is a sales technique, not a commercial reality, and it predicts how they will behave when you have questions.
• Unlimited revisions. Either they do not mean it, or nobody is protecting the timeline. Both are expensive.
• No questions about your business model during the first meeting. A team that does not ask what makes you money will build something that does not make you money.

You are not buying a website. You are buying the way a team makes decisions when the plan meets reality.

The cheap way to de-risk the whole thing

Before committing to a full engagement, buy a small, paid piece of work: a discovery sprint, a technical audit, a prototype of the hardest screen. A few thousand dollars buys you direct evidence of how they communicate, estimate and deliver — infinitely more informative than another reference call, and cheap insurance against a six-figure mistake.

More on this topic: Growth & Strategy.

Want this built for your business? See what we do.