Every software agency has a portfolio page. Most of them look impressive. Logos you recognise, products that sound complex, client quotes that are uniformly glowing. The problem is that a polished case study and a genuine delivery track record are two very different things — and the gap between them can cost a non-technical founder months of runway and a product built on shaky foundations.
Learning how to verify a software agency's case studies is not a nice-to-have skill. If you are at the point of shortlisting partners and preparing to sign a contract, it is the single most important due diligence step you can take. This guide gives you a structured, repeatable process to separate agencies that have genuinely done the work from those who have learned to describe it convincingly.
Why Agency Case Studies Are Frequently Misleading
The gap between 'we built this' and 'we owned this'
Portfolio inflation is not always deliberate fraud. More often, it is a framing problem. An agency may have contributed a payment integration module to a larger platform built by an in-house team and list that platform's brand in their portfolio. Technically accurate. Materially misleading.
The phrase 'we built X for Company Y' can mean anything from 'we architected the entire system from scratch' to 'we fixed three bugs on a Shopify theme during a two-week engagement.' Neither the logo nor the company name tells you which.
How portfolio inflation actually happens
Agencies accumulate work across many team configurations. Senior engineers who owned meaningful decisions may have left the firm. Sub-contractors may have delivered the core work while the agency managed the relationship. A white-label arrangement might mean the agency's name never appeared in the original contract at all.
After twelve years and more than fifty completed projects across SaaS, fintech, healthcare, and eCommerce, our team at Decyb has reviewed agency portfolios on behalf of clients during handover situations. A recurring pattern: the case study describes a product in full; the agency's actual scope was one integration layer. The client only discovers this when they need the agency to extend something they did not actually build.
What's at stake if you skip verification
The consequences are not abstract. If you hire an agency based on a misrepresented case study, you may be paying senior rates for a team that has never genuinely owned the architecture of a product like yours. You inherit technical debt you did not know was coming. Your launch slips. Your runway shortens. And six months later, you are back in the market for another partner — this time with less time and less money.
How to Evaluate a Software Development Partner: 9 Criteria
The Five Questions Every Case Study Must Answer
Before you book a discovery call with any agency, apply this filter to every case study in their portfolio. If a case study cannot answer all five, treat the gap as a data point.
1. What was the agency's specific scope — not the project's scope?
The case study should distinguish between what the overall product does and what the agency was specifically responsible for. 'We built a B2B marketplace' is a project description. 'We designed and implemented the multi-tenant supplier catalogue, retailer onboarding flow, and order management system on React and Node.js' is a scope description. The latter is verifiable. The former is not.
2. Who owned the architectural decisions?
Every non-trivial software product involves consequential architectural choices: the database design, the API structure, the authentication model, the infrastructure topology. Ask the agency who made those decisions and whether there is any written record of them — an Architecture Decision Record (ADR), a technical specification, or a trade-off log.
An agency that genuinely owned a product's architecture can walk you through at least three decisions they made and explain why they rejected the alternatives. An agency that managed a sub-contractor's work cannot.
3. What was the team composition and tenure?
Who actually worked on this? How long were they with the agency during the engagement? If the lead engineer left the firm eighteen months ago, the person presenting the case study today may have no first-hand knowledge of the work.
4. What happened after go-live?
The post-launch period is when the real quality of software becomes visible. Ask what the defect rate looked like in the first 90 days. Ask whether the client extended the engagement. Ask what they would do differently if they started the project today. Agencies with genuine ownership of their work can answer all three questions.
5. Can you speak to someone from that engagement?
A case study without an accessible reference is a story without a witness. We cover the reference process in detail below, but the willingness to connect you with past clients — and to do so without a two-week delay — is itself a signal.
Fixed-Price Software Contract: Is It Right for You?
Six Red Flags That Signal an Inflated Portfolio
These patterns appear repeatedly in agency portfolios that look credible on the surface but do not hold up under scrutiny.
1. Logo-dropping without defined scope
A portfolio page that features ten enterprise logos but no description of what the agency actually built for each of those companies is marketing collateral, not evidence. Logos are not deliverables.
2. No measurable outcomes — only features listed
Credible case studies include outcomes: time to market, system uptime, data accuracy improvement, scale metrics, or client-reported business results. A case study that describes only what was built — without any reference to whether it worked — is incomplete. Note that outcomes do not have to be revenue figures; they can be technical milestones (e.g., 99.9% uptime across 40,000+ retailer accounts) or operational improvements (e.g., manual reconciliation time reduced from four hours to fifteen minutes).
3. Team members who have since left
If the senior engineers whose experience justified the project no longer work at the agency, the capability may no longer exist there. Ask specifically which team members worked on the flagship case study and whether they are still with the firm.
4. Third-party platform reselling framed as custom build
This is particularly common in the eCommerce and CRM space. An agency that installs a GoHighLevel instance, configures its workflows, and skins its front end has delivered an implementation — which is a legitimate service — but they have not built custom software. The distinction matters when you need something the platform cannot do.
Similarly, a Shopify theme with modified CSS is not a 'custom eCommerce platform.' Ask for the tech stack. Ask what percentage of the core functionality runs on a third-party platform's APIs versus custom code the agency wrote and owns.
5. Timeline claims that defy physics
If a case study claims a full-featured multi-tenant SaaS was delivered in six weeks, ask for the sprint records or at minimum a milestone log. Compressed timelines are sometimes genuine — scope was tightly controlled, the team was experienced, nothing changed — but they warrant scrutiny. An agency that cannot explain how they achieved a compressed timeline probably cannot replicate it for you.
6. References who can't discuss technical specifics
A reference who enthusiastically endorses an agency's 'communication' and 'professionalism' but cannot tell you what the agency built or what problems arose during delivery is not a useful reference. They may be a genuine client who had limited technical involvement — or they may be a curated contact chosen for their willingness to give warm feedback without specifics.
How to Run a Technical Due Diligence Call
Once you have shortlisted two or three agencies based on the five-question filter above, request a technical due diligence call separately from the commercial discovery process. This should be a 30–45 minute conversation with a senior engineer — not a sales representative or account manager.
Request a 30-minute architecture walkthrough
Ask the agency to walk you through the architecture of one case study in their portfolio — ideally one that resembles your product's complexity. A credible agency will be able to draw the system's components from memory, explain the data flow, and identify the key integration points. They should be able to do this without referencing their marketing materials.
Architecture Decision Records (ADRs) are the gold standard here. If an agency maintains written records of why they made key technical decisions — and can share a redacted version — that is strong evidence of a disciplined engineering culture.
Ask about specific trade-off decisions made
Every architectural decision involves trade-offs. Ask: 'What was the main alternative you considered for [a specific component], and why did you reject it?' An agency that genuinely owned the decision can answer this immediately. An agency that managed the work without owning it will give you a vague or deflecting answer.
Probe the failure moments: what went wrong and how was it resolved?
This is the most revealing question you can ask in a technical conversation. Every real project has a moment where something did not go to plan — a dependency that behaved differently in production, a scope assumption that turned out to be wrong, a performance issue that appeared under load. An agency that claims a project was entirely smooth is either misremembering or not being candid.
A team that can describe what went wrong, what they did to resolve it, and what they changed in their process as a result is a team that learned from the engagement. That is exactly the kind of partner you want.
Request access to any public repositories or staging environments
For open-source or public projects, ask for the repository link. Review the commit history: does it show continuous, disciplined engineering activity or large batched commits suggesting code was dumped in at the end? For client projects, a staging environment or redacted schema diagram may be available. Not every agency will be able to share these due to NDA obligations — but the willingness to offer what they can, and to explain clearly what they cannot, is itself informative.
What Is Clean Architecture in Software? Founder's Guide
Reference Checks: How to Get Honest Answers
Always find at least one reference the agency didn't give you
Agency-provided references are curated. That does not make them dishonest — every business highlights its best relationships — but they represent a selected sample. To get a more complete picture, source at least one reference independently.
Start with LinkedIn. Search for the company name in the case study and look for past employees or product leads who may have overlapped with the engagement period. Public freelance platform profiles (Upwork, Toptal, Clutch) often contain independently timestamped reviews that cannot be edited or deleted by the agency. Company registration records, GitHub profiles, and ProductHunt listings can surface additional contacts.
Independently verifiable platform ratings carry more evidential weight than testimonial quotes on an agency's own website. A testimonial appears because the agency chose to publish it. A ★ 5.0 rating on a platform from 2014 through 2025 across twelve or more years of engagements is a different category of evidence: it is timestamped, searchable, and not editable by the rated party. [VERIFY: confirm platform review policies for editability on Upwork/Clutch]
The questions that reveal the real relationship
When you speak with a reference, resist the urge to ask 'was the agency good?' Ask instead:
- 'If you were starting this project again, what would you ask the agency to do differently?'
- 'Did the project deliver what was in the original scope, or did scope change significantly?'
- 'Who on the agency's team was most valuable — and are they still there?'
- 'Did you extend the engagement after the initial project? Why or why not?'
- 'What would you warn a new client to watch out for?'
These questions make it harder to give a reflexively positive answer and more likely to surface genuine texture about the engagement.
Reading between the lines of a 'mostly positive' reference
Pay close attention to what is not said. A reference that praises communication and design sensibility but never mentions technical quality or on-time delivery may be signalling something. A reference who says 'they were great for what we needed at the time' may be indicating that the agency's capability did not scale with the project's needs.
Building Your Verification Checklist: A Step-by-Step Process
Here is a repeatable process you can apply across every agency you are evaluating, producing a consistent basis for comparison.
Step 1: Audit the case study document itself
For each portfolio item, apply the five-question filter from the earlier section. Score each question: fully answered, partially answered, or not addressed. Any case study with two or more unanswered questions should prompt a direct follow-up request before you proceed.
Note whether the case study describes scope specifically, includes measurable outcomes, identifies the technology stack, mentions post-launch performance, and provides a named or linkable reference.
Step 2: Run independent discovery
Before you make contact with the agency, research the companies mentioned in their portfolio. Search for the product's public presence (App Store reviews, G2 ratings, LinkedIn company pages). Search for the agency's name alongside the company name. Look for any public engineering content — blog posts, conference talks, open-source contributions — that confirms technical depth.
This step takes 30–60 minutes per agency and will often surface useful context before you have spent any of your time in calls.
Step 3: Conduct the technical call
Book a 30–45 minute session with a senior engineer (not a sales lead). Use the architecture walkthrough format described above. Take notes on how specific, how candid, and how technically precise the answers are. An agency that prepares a slide deck for this call but struggles with unscripted questions is a different signal from one that speaks fluidly from experience.
Step 4: Complete the reference sweep
Contact the references the agency provides. Then independently source at least one additional reference. Ask the questions listed above. Consolidate your notes.
Step 5: Score and compare shortlisted agencies
Create a simple scoring matrix with your evaluation criteria as rows and agencies as columns. Weight the criteria according to your priorities — technical ownership, post-launch support, communication style, verifiable outcomes — and score each agency consistently. The process disciplines your own thinking and makes the final decision defensible to stakeholders.
For an agency quoting fixed-price engagements, verify that the scope document is detailed enough to make the price meaningful. A fixed price on a vague scope is not a financial protection — it is a setup for disputes. [INTERNAL LINK: Fixed-Price Software Contract: Is It Right for You?]
Frequently Asked Questions
How do you verify a software agency's case studies?
Apply a five-step process: audit the case study document against a defined question set (scope, architectural ownership, team tenure, post-launch performance, accessible references), run independent research before any calls, conduct a technical architecture walkthrough with a senior engineer, complete a reference sweep including independently sourced contacts, and score agencies consistently against the same criteria.
What are the biggest red flags in a software agency portfolio?
Logo-dropping without defined scope, feature lists with no measurable outcomes, team members who have since left the agency, third-party platform implementations framed as custom builds, timeline claims with no milestone evidence, and references who cannot speak to technical specifics.
Should I ask for references the agency didn't give me?
Yes — always. LinkedIn, Clutch, Upwork, and ProductHunt can surface past clients and team members independently of any curated list. Independently timestamped reviews on third-party platforms carry significantly more evidential weight than testimonials on an agency's own website.
What questions reveal whether an agency truly owned a project?
Ask who made the architectural decisions, what alternatives were considered and rejected, what failed during the engagement and how it was resolved, and whether there is a written decision log or Architecture Decision Record. These questions are difficult to answer convincingly without first-hand ownership.
How can I tell if a 'custom build' is really a SaaS or no-code reskin?
Request a walkthrough of the tech stack. Ask what percentage of the core functionality runs on a third-party platform's API versus custom code the agency wrote. Ask for a redacted schema or component diagram. If the agency hesitates to answer these questions, that is a meaningful signal.
How Decyb Technology LLP Invites Scrutiny — and Why That Matters
The verification process described in this guide is exactly the process we encourage every prospective client to apply to us. Not as a formality — because we believe it is the only honest basis for a working relationship.
Here is what that looks like in practice.
What our case studies actually contain
Our portfolio includes detailed scope descriptions, technology stack specifics, and measurable outcomes for each engagement. The FieldFolio project — a B2B wholesale marketplace serving 40,000+ retailers across Australia and New Zealand — includes the full architecture decision document covering multi-tenant design, retailer onboarding flow, supplier catalogue synchronisation, and order management architecture. The Multiverse restaurant management system case study includes component diagrams, the online order integration flow, and back-office reporting screenshots. Our Meta Conversions API implementation work includes before-and-after data completeness comparisons showing the impact of server-side event deduplication.
These are not summary descriptions. They are the kind of documentation you would expect from an engineering team that genuinely owned what it built.
How to verify our track record independently
Our ★ 5.0 ratings span client engagements from 2014 through 2025 across international freelance platforms. These ratings are independently timestamped and not editable by us. They include reviews from clients who have retained our team across ten or more years in multiple technical capacities — the kind of long-term retention that happens when delivery is consistent, not when a portfolio looks impressive.
You can search for our work independently. You can ask to speak with past clients before you commit to anything. You can request a technical walkthrough of any case study in our portfolio. If any of those requests creates friction, you should treat that friction as information. With us, it will not.
For clients who want to understand our engineering standards, our work is grounded in OWASP security guidelines [Source: OWASP Top Ten], clean architecture principles [Source: Martin Fowler], and the performance standards outlined by Google's web performance guidance [Source: web.dev]. These are not aspirational references — they are the benchmarks our team uses in scoping and code review.
What happens on your free strategy call
The free 24-hour technology strategy call is not a sales conversation disguised as advice. It is a working session with a senior partner who will review your product brief, identify the architectural decisions that matter most at your stage, and give you an honest assessment of where custom development is warranted and where it is not.
If you come in with a portfolio verification question — about us or about another agency you are evaluating — we will engage with it directly. If we are not the right fit, we will tell you.
If you are at the stage of shortlisting technical partners and want to apply the framework in this guide to a real conversation, book the strategy call. You will leave with a clearer picture of what you need — regardless of who you choose to build it with.
Book your free strategy call — get a plan in 24 hours.