01Write the scope before the shortlist
Companies can only be compared against a clear need. Summarize the outcome, the users, the essential journeys, the systems involved and your launch window first. A written brief turns a comparison of portfolios into a comparison of approaches to your project — and it lets every company answer the same question.
02Build the shortlist from more than one source
Referrals from people who ran similar projects, review directories such as Clutch, GoodFirms and DesignRush, and technology-partner listings each surface different companies. Directories publish ranking methodologies and some show sponsored placements, so read how a list is ordered before treating it as a recommendation. Three to five companies is usually as many as you can evaluate properly.
03Look for evidence that matches your project
A strong portfolio shows what a company can make; it does not show how it would handle your constraints. Ask for evidence that is specific to your scope.
- A walkthrough of a comparable workflow or integration, not only screenshots.
- The named people who would work on your project, and their availability.
- References from clients with a similar scope, ideally for products now in production.
- An honest account of a project that went wrong and what changed afterwards.
04Ask questions that reveal how they work
The best early conversations are about your risks, not the company’s credentials. These questions separate teams that have thought about your project from teams that are selling a standard package.
- What would you need to know before you could estimate this?
- Which of our requirements carry the most risk, and how would you reduce it?
- How do you handle scope changes, and how are they priced?
- Who owns the code, accounts and documentation, and when do they transfer?
- What does support look like after launch, and how quickly do you respond?
05Watch for warning signs
None of these proves a company is unsuitable, but each deserves a direct question before you sign.
- A confident price before anyone has asked about your users, data or integrations.
- No named team, or a team that changes after the contract is signed.
- Vague assumptions and no list of exclusions.
- Pressure to sign quickly, or to pay most of the fee up front.
- Code, accounts or intellectual property retained by the company by default.
06Score every company the same way
Agree your criteria before reading proposals, weight them by what matters for this project and score each company against the same scope. A shared scorecard keeps a polished presentation from outweighing evidence.
- Relevant experience: comparable work that is running in production.
- Understanding of your scope: the risks and questions they raised unprompted.
- Team: named people, their seniority and their availability.
- Delivery approach: how they plan, test, report progress and handle change.
- Commercial terms: the model, assumptions, exclusions, ownership and support.
07Compare proposals, then decide
Normalize every proposal against the same checklist before comparing totals; a lower figure often leaves out work another company included. Then check references, agree contractual protections and keep your own record of why you chose. Scopeivo is not a development agency; this process applies whichever companies you consider.
Editorial approach
This guide offers practical planning questions. It is not a guarantee of delivery outcomes. Adapt the checklist to your project and validate assumptions with the proposed team.
Further reading: GOV.UK Service Manual — related delivery guidance
