How to Evaluate a Software Development Agency's Portfolio (Red Flags Included)
To evaluate a software development agency's portfolio, look beyond visual polish and check for three things: evidence that the agency understood a real business problem, measurable outcomes for the client, and technical decisions that hold up to scrutiny. An agency that cannot clearly explain why they built something a particular way is one to avoid — regardless of how good the screenshots look.
Why Portfolio Evaluation Matters More Than Sales Calls
UK businesses that have been through a bad agency experience often describe the same pattern: impressive pitch, confident promises, and then a delivered product that does not quite work, cannot be maintained, or locks the client into a proprietary system they never fully understood. The portfolio is the one place where an agency's real track record is visible before you commit any budget. Knowing how to read it properly is the most practical defence you have.
Step-by-Step: How to Evaluate a Software Agency Portfolio
- Start with the problem, not the product. Every case study should open with a clear description of the business problem the client faced. If the write-up leads with technology choices or design awards rather than the client's actual situation, that is an early signal the agency is more interested in its own story than the client's outcome.
- Look for specificity in outcomes. Strong portfolios cite concrete results: hours of manual work eliminated, a process that previously took a team member half a day now handled automatically, a tool that replaced three spreadsheets and a weekly reconciliation meeting. Vague language like 'improved efficiency' or 'transformed operations' without any supporting detail should make you probe further.
- Check whether the tech stack matches the problem. A well-chosen stack is appropriate to the scale and lifespan of the project — not whatever the agency happens to prefer. Ask the agency to walk you through a past project's technical decisions. If they struggle to explain why they chose a particular approach, or default to buzzwords, that is a sign the thinking was shallow.
- Ask who actually built it. In the UK, it is common for agencies to present work that was delivered by offshore subcontractors or freelancers who are no longer involved. There is nothing wrong with distributed teams, but you need to know who will be building your tool, and whether the people pitching you are the ones who will actually write the code.
- Look for post-launch evidence. A project going live is not the finish line. Ask whether the client is still using the tool 12 or 24 months later, and whether the agency supported any changes after launch. Abandoned tools and clients who moved on quickly are meaningful data points worth asking about directly.
- Contact a reference client if possible. Portfolio pages are curated. A 15-minute call with a past client will tell you more than ten case studies. A credible agency will offer references without hesitation. Reluctance to provide them is a red flag in itself.
- Assess the maintainability of the work. Ask the agency: if we wanted to take this codebase in-house or move to a different supplier, what would that involve? Agencies who build on proprietary internal frameworks, obscure tooling, or undocumented code create dependency by design. Good agencies build software that another competent developer can pick up.
Red Flags to Watch For in a Software Agency Portfolio
Some warning signs are subtle enough that they only stand out if you know what you are looking for. The following patterns appear repeatedly in UK businesses' accounts of poor agency experiences.
| Red Flag | What It Usually Means | What to Do |
|---|---|---|
| Every case study features a different industry and tech stack | The agency has no focused expertise and may be learning on your project | Ask for examples closest to your sector and use case |
| No mention of the client's business problem, only the deliverable | Outputs-focused rather than outcomes-focused thinking | Ask directly: what problem did this solve, and how do you know it worked? |
| Portfolio work is all front-end or design-led | May lack backend and data engineering depth for complex tools | Request examples of internal tools, integrations, or data-heavy builds |
| Case studies use mock-up screenshots rather than real product interfaces | Work may be conceptual or the relationship may have ended badly | Ask to see a live demo or speak to the end user |
| Timeline and budget are never mentioned | Agency may avoid accountability on delivery | Ask what the original brief was and how the final scope compared |
| All testimonials are short quotes with no attribution | May be fabricated or unverifiable | Cross-reference on LinkedIn or ask for an introduction to the named contact |
| The agency cannot explain a technical decision in plain English | Indicates either shallow thinking or deliberate obscurity to create dependency | Press them: why this approach over the alternatives? |
Questions to Ask During the Portfolio Review Meeting
A portfolio review meeting is not a presentation — it is an interview. You are assessing whether this agency thinks clearly about problems, is honest about trade-offs, and will treat your project with the same rigour they applied to their best work. The following questions are designed to surface the difference between agencies that genuinely deliver and those that are good at winning business.
- Walk me through a project that did not go to plan. What happened and what did you do?
- Which project in your portfolio are you least proud of, and why?
- If the client in this case study came back to you today, what would you do differently?
- How do you handle scope changes mid-project?
- What does handover look like — documentation, training, source code access?
- Have any of your clients had to rebuild a tool you delivered? If so, why?
Tip
The best agencies welcome hard questions and answer them with specifics. If an agency responds to 'what went wrong on a past project?' with nothing but positives, treat that as a signal — not a reassurance.
What Good Portfolio Evidence Actually Looks Like
A strong portfolio case study for a UK software agency typically reads something like this: a specific UK business in a recognisable sector, a clearly articulated operational problem (manual data entry, disconnected systems, a process that broke under growth), a described solution with a rationale for the approach, and a concrete outcome the client can confirm. Bonus points if the agency is candid about constraints — budget, timeline, technical limitations — and explains how they navigated them. That kind of honesty signals an agency that is used to working within real-world conditions, not just greenfield demos.
Choosing Between Agencies: A Practical Comparison Frame
| Criterion | Strong Agency | Weak Agency |
|---|---|---|
| Problem clarity | Describes the client's business context in detail | Leads with the technology or the deliverable |
| Outcome evidence | Specific, verifiable results tied to the tool | Vague claims about improvement or transformation |
| Technical rationale | Can explain trade-offs and why this approach was right for this project | Defaults to buzzwords or cannot go deeper than the surface |
| Honesty about limitations | Discusses constraints and compromises openly | Every project is presented as a perfect success |
| Maintainability | Builds for handover; clean, documented, portable code | Proprietary frameworks, no documentation, lock-in by default |
| References | Offers introductions to past clients readily | Provides only curated quotes or redirects to testimonials page |
Note
For UK businesses replacing spreadsheets or manual processes with proper tools, the most relevant portfolio evidence is internal tooling work — not polished consumer apps. Ask specifically for examples where the agency built something used daily by an operations or admin team.
How Bedrock Team Approaches Portfolio Transparency
At Bedrock Team, we apply these same criteria to how we present our own work. We build custom apps and internal tools for UK businesses, and we are happy to walk you through not just what we built, but why we made specific technical decisions, what constraints we were working within, and what the client can do independently now the project is done. If you are currently shortlisting agencies, we are happy to have a straight conversation about whether we are the right fit for what you need — and equally honest if we are not.