How to Review a Software Company's Portfolio (Beyond the Screenshots)

A portfolio is the only sales document buyers accept at face value. Contracts get redlined. Proposals get cost-modelled line by line. References get called and cross-checked. But the screenshots on an agency’s work page usually get a scroll, a nod, and a place on the shortlist.

That asymmetry is expensive, because the portfolio is the input that shapes which three vendors make the final round  and it is also the input with the weakest evidentiary standard in the entire procurement process. A screenshot proves a design file existed. It does not prove the product shipped, the agency built it, or that the team who built it still works there.

Research by McKinsey and the University of Oxford across more than 5,400 IT projects found that large IT projects run 45% over budget and 7% over schedule while delivering 56% less value than predicted  with software projects carrying the highest overrun risk of any category. 

Those overruns rarely start at the code level. They start at selection, when a buyer picks a partner whose demonstrated capability was assumed rather than confirmed. Knowing how to check a software company portfolio properly costs roughly 60–90 minutes per vendor, and it is the highest-leverage hour in any step-by-step process for hiring a software development company.

This guide covers five verification steps that move a portfolio from marketing asset to evidence: demanding live URLs and app store links, checking launch dates against the Wayback Machine, spotting a recycled UI kit across supposedly unrelated clients, pinning down which parts the agency actually built, and confirming outcomes with the client rather than the vendor. Each step takes minutes. Together they eliminate most of the vendors who would have cost six figures to discover the hard way.

What Checking a Software Company Portfolio Actually Means

How to check a software company portfolio refers to the process of independently verifying that the projects an agency claims are real, shipped, built by that agency’s own team, and comparable in scope to your project  using live product links, archival launch records, technical questioning, and direct client confirmation rather than the visuals the agency supplies.

The distinction matters. Reviewing a portfolio is passive. Checking one is adversarial in the same way a code review is adversarial: you assume the artifact is wrong until specific tests pass.

The Core Problem: Portfolios Are Optimized for Shortlisting, Not Accuracy

Most agency work pages are assembled by a marketing contractor working from a Notion doc, not by the engineers who shipped the product. The result is a document with no chain of custody. Nobody in the agency can tell you, without asking around, which of those 24 tiles represents a full build versus a three-week UI refresh.

Three specific distortions recur often enough to plan for. Each one survives a casual review and fails a five-minute check.

The first is attribution inflation. An agency that supplied two contract React developers to a client’s in-house team will present the client’s product as a portfolio project. This is common in staff augmentation shops that market themselves as end-to-end product studios, and the language gives it away: “worked with,” “partnered on,” and “contributed to” are doing heavy lifting where “built” would be a legal risk.

Second, white-label development creates circular portfolios. Agency A subcontracts a build to Agency B. Both display it. Neither is lying, exactly, but only one has the engineering capability you are paying for. In markets like mobile and enterprise integrations, a single delivery team can appear in six different agencies’ portfolios.

Third is the outright fake portfolio software company, a shell operation running a template site with stock product mockups, invented client logos, and a five-person “team” page built from stock photography. These are rarer than procurement folklore suggests, but they cluster in low-cost sourcing channels and directory listings where nobody verifies anything before publishing, alongside the other red flags in a software development company that usually surface far later in a deal.

The financial exposure is concrete. A mid-size product build sits at $60,000–$250,000 and 4–9 months. Discovering in month three that your vendor’s flagship case study was subcontracted costs you the sunk cost plus a 6–10 week re-tendering cycle. Front-loading verification turns that into a 90-minute task.

How to Check a Software Company Portfolio: The 5-Step Verification Process

Run these five steps in order. Steps 1–3 are unilateral; you can do them without contacting the agency, which means you can disqualify vendors before spending a single meeting. Steps 4 and 5 happen in the first call and the reference stage.

1. Demand live URLs and app store listings for every claimed project.
2. Check launch dates and site history in the Wayback Machine.
3. Compare UI systems across “different” clients for recycled components.
4. Ask which specific parts the agency built and who on staff built them.
5. Confirm outcomes with the client, not the vendor.

Step 1: Ask for Live Project Links and App Store Listings

The single most effective filter is also the simplest. Ask for live project links, a production URL, an App Store or Google Play listing, a public repository, or a logged-in demo environment  for the three projects closest to your scope.

A legitimate agency answers this in one email. Perhaps two of five projects are behind NDA or have since been sunset; that is normal and they will say so specifically, naming the constraint. What is not normal is deflection: “the client asked us not to share,” applied uniformly to every project in a public portfolio.

Check the app store listing carefully once you have it. The developer account name is public, review counts and release history are public, and the “Updated” date tells you whether the product is maintained or abandoned; the same public signals do most of the work when you vet a mobile app development company. A 2019 app with no release since launch is a different signal than one shipping monthly.

For web products, confirm the live site still matches the portfolio screenshot. Wholesale divergence usually means the client rebuilt with someone else  worth asking about, and worth noting the agency chose not to mention.

Step 2: Check Launch Dates Against the Wayback Machine

Pull each live URL into the Internet Archive’s Wayback Machine and find the earliest capture showing the product in something like its current form. You are looking for one thing: a launch date that predates the agency’s own existence.

Cross-reference three dates: the first meaningful archive capture, the agency’s domain registration (a WHOIS lookup takes 30 seconds), and the founding date on their LinkedIn company page. A 2015 product in the portfolio of a company incorporated in 2021 is not automatically fraud; the founders may have built it at a previous employer. But it is a question that must be asked out loud, and the answer feeds straight into how you select the best IT company from a shortlist.

The archive also reveals redesign timelines. If the agency claims a 2023 rebuild and the archive shows the interface unchanged since 2020, the engagement was something other than what the case study describes.

Step 3: Look for the Same UI Kit Across “Different” Clients

This is the step most buyers skip and the one that surfaces the most portfolios worth abandoning. Open four or five projects side by side and compare them as a designer would, not as a prospect would.

Look for identical empty-state illustrations, the same icon family, matching modal and toast patterns, identical table row heights and filter chips, and dashboard layouts that differ only in accent color. Open developer tools on two live sites: shared class-name conventions, the same component library version, and identical font stacks are strong evidence of a single recycled template.

Knowing how to check a software company portfolio at this level takes twenty minutes and separates a product team from a theme-configuration shop. Some template reuse is legitimate and even efficient; a strong internal design system is an asset, and the custom versus template cost gap exists for good reason. The problem is an agency selling custom product development while delivering the same admin template with a new logo, which is a portfolio red flag worth pricing in before you sign.

Ask directly: “Is this your internal design system, or was each of these built from scratch?” Either answer is workable. An evasive answer is not.

Step 4: Ask Which Parts the Agency Actually Built

Build ownership is the question that collapses the most impressive-looking portfolios. Put it in writing during project scoping, before the commercial conversation:

• Which components did your team write versus inherit or integrate?
• Did any part of this delivery go to a subcontractor or partner agency?
• Who owns architecture decisions, your team or the client’s CTO?
• Are the engineers who built this still employed here, and are they available for our engagement?
• Can you walk us through the commit history or a technical decision you reversed?

That last item is the hardest to fake. Any engineer who genuinely shipped a system can describe, unprompted, a decision that went wrong and what replaced it, a queue that had to be reworked under load, a schema migration that forced a weekend rollback. Marketing teams cannot manufacture this detail and subcontracted deliveries cannot recall it, which is why it belongs in the core set of questions to ask a software development company.

The staffing question carries independent weight. Agencies with 40–60% annual engineering turnover routinely sell a portfolio built by people who left 18 months ago. The projects are real. The capability is gone.

Step 5: Verify Agency Case Studies With the Client

Reference calls exist, but most are theater: the agency selects a friendly contact, briefs them, and the buyer asks questions that invite compliments. To actually verify agency case studies, change who you talk to and what you ask.

Request references for the two projects in the portfolio closest to your scope, not the agency’s choice of reference. Then ask questions with falsifiable answers: What was the original timeline versus the delivered timeline? What was the change-order total as a percentage of the initial contract, and how did their change order process handle it? Who on the agency side was replaced mid-project, and how was the handover managed? Would you be able to hire them again under the same terms?

LinkedIn provides an independent path when the formal channel stalls. Find an engineer or PM who was at the client company during the stated engagement window and message them directly. A two-line reply confirming the vendor relationship is worth more than an hour of curated client references.

Where NDA restrictions genuinely apply, ask for a redacted case study with verifiable structure: real timelines, real team composition, real technical constraints, anonymized client. A vendor who cannot produce that under NDA is usually protecting something other than the client.

What Verification Looks Like in Practice

A Series A fintech team shortlisting three development partners ran Steps 1–3 before booking any calls. One vendor’s three “independent” client dashboards shared identical empty-state illustrations and the same component library version, and the Wayback Machine dated two of the products to 18 months before the agency’s incorporation. Total time spent: 40 minutes. The engagement under discussion was quoted at $180,000.

In a second case, an enterprise procurement lead sourcing a healthcare data platform made build-ownership disclosure a mandatory field when writing the software development RFP, across six vendors. Two withdrew rather than answer; a third disclosed that roughly 70% of its flagship case study had been subcontracted to an offshore partner. The selected vendor delivered in 5 months against a 7-month baseline, with change orders at 8% of contract value, and the entire filter cost two days of procurement time.

A Framework for Grading Portfolio Evidence

Not all evidence is equal, and treating it as equal is why strong-looking portfolios pass weak vetting. Grade each claimed project by the strongest evidence available for it, then fold that grade into a wider buyer framework for comparing software development companies, so your top two vendors clear Tier 3 or better on at least two projects matching your domain expertise requirements.

Platform-level verification reduces the floor of this work rather than replacing it. Marketplaces that screen website ownership, email domains, team details, and review history before a profile goes live  the model GetProjects uses  eliminates the shell-company tier entirely, which means your 90 minutes goes toward build ownership and team retention instead of confirming the company exists.

What Most Teams Get Wrong When They Evaluate an Agency Portfolio

The dominant failure in vendor vetting is not gullibility. It is grading on volume.

Buyers consistently rank a portfolio of 40 projects above a portfolio of 6, when the opposite is usually the correct read. Forty tiles across eight unrelated industries in four years, from a 25-person shop, is arithmetically improbable as deep work  it describes a firm that takes anything, subcontracts overflow, and has no repeatable delivery model. Six documented projects in one domain, with named engineers and live links, is a far stronger signal for anything beyond commodity work.

The second error is scope mismatch blindness. A stunning portfolio of marketing sites and Shopify builds tells you nothing useful about a vendor’s ability to deliver a multi-tenant SaaS platform with role-based permissions and SOC 2 requirements. Teams evaluate agency portfolio quality on visual polish because polish is easy to assess, and they skip the question of whether any project in it shares your system’s actual complexity class.

Third, and most costly: nobody checks whether the portfolio team still exists. The right question is never “did you build this,” it is “who built this, are they here, and are they on my project.” An agency that answers with names, tenure, and availability is a different risk profile than one that answers with a company pronoun.

There is also an underrated positive signal. An agency that volunteers a project that went badly, an overrun, a scope reset, a client that churned  and explains what changed in their process afterward is demonstrating something no curated portfolio can. Applying how to check a software company portfolio well means weighting that disclosure as heavily as any polished case study.

Before You Shortlist

Verification fails most often because of sequencing, not skill. Teams run these checks after they have emotionally committed to a vendor, at which point every red flag gets explained away; the fix is the same discipline that lets a team shortlist an IT agency in 72 hours instead of six weeks.

Run Steps 1–3 before the first call. They are unilateral, they take under 30 minutes per vendor, and they will remove one or two names from a five-vendor list without a single meeting.

If you are sourcing a development partner and would rather spend that time on build ownership than on confirming a company is real, GetProjects screens website ownership, email domains, team details, and review history before any agency profile goes live, and matches projects to vetted partners with no bidding and no commission on either side. Post a project in under two minutes at getprojects.ai  or use the five steps above on whatever shortlist you already have.

Frequently Asked Questions

Is it normal for a software company to hide client names? 

Yes, in regulated sectors and enterprise work, NDAs routinely prohibit naming clients. What is not normal is blanket anonymity across an entire portfolio with no verifiable substitute. A credible vendor will offer a redacted case study with real timelines, team composition, and technical constraints, or arrange a reference call under mutual NDA.

Can a software company show projects it didn’t build? 

It happens frequently and is rarely illegal. Subcontracted deliveries, white-label arrangements, and staff-augmentation engagements all produce projects an agency can display with some justification. This is exactly why build-ownership questions belong in your first call rather than your contract review, and why authorship should be confirmed per project.

How do I verify agency case studies when the client is under NDA? 

Ask for structural verification instead of identity: original versus delivered timeline, team size and roles, change-order percentage, and the specific technical constraints involved. Then request a reference call where the client speaks to process without naming their product. LinkedIn confirmation from a former employee at the client is a reliable independent check.

What are the biggest portfolio red flags in a dev agency? 

Uniform NDA claims across every project, no live URLs anywhere, identical UI components across unrelated clients, launch dates predating company incorporation, vague authorship verbs like “partnered on,” and an inability to name the engineers who shipped a given project. Any one is a question. Three together is a disqualification.

Do app store listings prove an agency built the app? 

No. A listing proves the product shipped and shows its maintenance history, developer account, and review volume  all useful, none of which establish authorship. Pair the listing with build-ownership questions and a client reference before treating it as proof of capability.

How long should portfolio verification take per vendor? 

Budget 60–90 minutes per shortlisted vendor: 20 minutes on live links and archive checks, 20 on UI comparison, and 30–45 on build ownership and references. Across a three-vendor shortlist that is roughly four hours  negligible against a $60,000–$250,000 engagement, and the cheapest risk reduction available in the process. If that overhead is the blocker, working from a pre-verified vendor pool removes the first half of it.