Choosing a digital product partner is one of the higher-stakes decisions a head of digital makes, and the sales process is designed to make every option look the same. This is a practical guide to seeing past the pitch: define the outcome first, ask the questions that surface real capability, and compare proposals on what you are actually left with.
Start with the outcome, not the vendor
Most flawed selections start the same way: a shortlist of agencies is drawn up before anyone has agreed what success looks like. You end up comparing vendors against each other rather than against your goal, and the best presenter wins. Reverse the order. Write down the outcome you need in concrete terms before you talk to anyone.
A usable outcome statement names the user, the problem, the measurable change, and the constraint. "A self-service portal that lets case handlers submit applications without phoning the contact centre, live to a first cohort within three months, accessible to WCAG 2.2 AA" tells a partner far more than "modernise our intake process". It also gives you a fixed point to score every proposal against.
If you are still deciding whether to build at all, settle that first. Our build vs buy framework covers when bespoke development is worth it and when an off-the-shelf product will do. There is no point selecting a build partner for a problem that a configuration project would solve.
The questions that surface real capability
Capability shows in the answers to specific operational questions, not in case-study slides. The following work well in a first or second conversation, and the quality of the answer matters more than the answer itself.
On the team and who does the work
- Who will actually be working on this day to day, and will they be the same people who pitched? Ask for the working team, not the leadership that turns up to win the deal.
- Is this a cross-functional team that owns the outcome, or individuals you will have to coordinate yourself? A team that brings product, design and engineering together can move without you in the middle of every decision.
- How do they handle a key person being unavailable? If the answer depends on one named individual, you are carrying that risk.
On discovery and de-risking
- How do they run discovery, and what comes out of it? You want a short, evidence-led phase that tests the riskiest assumptions early, not a six-week document factory.
- How do they de-risk delivery? Look for thin slices shipped to real users, working software early, and a habit of validating rather than assuming.
- What happens when discovery shows the original plan is wrong? A partner who will tell you that, before the budget is spent, is worth more than one who simply builds what was asked.
On handover, security and accessibility
- What is the plan for leaving your team self-sufficient? Knowledge transfer, documentation and pairing should be part of the engagement from the start, not a scramble at the end.
- How do they handle security and accessibility in practice? Ask for the specifics: where these sit in the delivery process, and evidence from past work. For UK public sector and regulated work, WCAG 2.2 AA and a credible security posture are table stakes, not optional extras.
- Can you speak to two or three references directly, including one engagement that did not go smoothly? How a partner handled a hard project tells you more than a polished success.
A quick test for any partner
Ask: "When this is finished, what will my team be able to do that they cannot do today?" If the answer is only "you will have the product", you are buying output. If the answer includes the skills, patterns and confidence to keep building, you are buying capability. The second is what lasts.
Red flags
Some patterns reliably predict a painful engagement. None is automatically disqualifying, but each one shifts risk onto you and deserves a direct question.
- Body-shopping. You are sent CVs and day rates rather than a team. You become the integrator, the planner and the quality bar, which is rarely what you wanted to outsource.
- No discovery. A fixed scope and a fixed price quoted before anyone has examined the problem usually means the risk gets passed back to you through change requests.
- Hero individuals. The pitch leans on one brilliant person. When they move on, the engagement stalls.
- Vague pricing. Open-ended time and materials with no shape, or a fixed price with no defined outcome, both make it hard to know what you are buying.
- No exit plan. If nobody can explain how your team ends up self-sufficient, you are signing up for permanent dependency.
Agency, consultancy or staff augmentation
The word "agency" covers very different models, and the difference changes who carries the risk. It helps to be clear about which you are actually evaluating.
- Staff augmentation gives you individual contractors to fill gaps. You keep ownership of the product, the plan and the management. It works when you have a strong team and a known gap, and it struggles when you need someone to own the outcome.
- A delivery agency takes a brief and builds to it. This works for well-defined projects and is weaker when the problem is still ambiguous or the strategy is unsettled.
- A product consultancy owns the outcome with you, runs discovery, and brings a cross-functional team that can take a problem from question to working product. The trade-off is that it is a partnership, not a transaction, so it asks more of you up front.
We work as a consultancy. For the fuller picture of what that means, see what a digital product consultancy does. If you are weighing a team against contractors, product squad vs staff augmentation lays out the difference, and agency vs in-house product team covers the build-or-buy question for the team itself.
How we are set up to deliver
Our model is the self-contained cell: a cross-functional squad of product, design and engineering that delivers value from day one and can ship a real-world digital product in fewer than 100 days. The squad owns the outcome, so you are not the integration layer between separate specialists. You can see this in our DEFRA work, where the platform now handles more than 14 million transactions a year to public-sector accessibility standards, and in Motive Partners, an event-driven FinTech build delivered to enterprise expectations.
The deliberate end state is that you keep the capability. Alongside building the product, we transfer the practices and confidence your team needs to carry it forward, which is the focus of our digital capabilities work. A good partner should make itself less necessary over time, not more.
How to compare the proposals you get back
Once the proposals land, resist scoring on day rate alone. The cheapest rate often hides the highest total cost once you add the management overhead and the capability you never gained. Run each proposal through the same checklist.
- Outcome. Does the proposal restate your outcome in measurable terms, or does it just list features and hours?
- Team. Is it a cross-functional team that owns the result, and are the named people the ones who will do the work?
- Discovery. Is there a real discovery phase that tests the riskiest assumptions before the build commits?
- De-risking. Does the plan ship working software to real users early, in thin slices?
- Standards. Are accessibility and security built into the delivery process, with evidence rather than assurances?
- Handover. Is knowledge transfer part of the engagement, with a clear picture of what your team can do afterwards?
- Pricing. Is the price tied to a defined outcome, so you can see what you are buying and what would change it?
Score every proposal against the same seven points and the right partner usually separates from the field quickly. If you want to test your own outcome statement before you go to market, talk to us and we will walk through it with you.