{"id":2516,"date":"2026-09-16T06:11:16","date_gmt":"2026-09-16T06:11:16","guid":{"rendered":"https:\/\/getprojects.ai\/blog\/?p=2516"},"modified":"2026-09-16T06:11:16","modified_gmt":"2026-09-16T06:11:16","slug":"how-to-check-a-software-company-portfolio","status":"publish","type":"post","link":"https:\/\/getprojects.ai\/blog\/how-to-check-a-software-company-portfolio\/","title":{"rendered":"How to Review a Software Company’s Portfolio (Beyond the Screenshots)"},"content":{"rendered":"

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.<\/span><\/p>\n

That asymmetry is expensive, because the portfolio is the input that shapes which three vendors make the final round\u00a0 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.<\/span><\/p>\n

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

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\u201390 minutes per vendor, and it is the highest-leverage hour in any<\/span> step-by-step process for hiring a software development company<\/b><\/a>.<\/span><\/p>\n

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.<\/span><\/p>\n

What Checking a Software Company Portfolio Actually Means<\/b><\/h2>\n

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\u00a0 using live product links, archival launch records, technical questioning, and direct client confirmation rather than the visuals the agency supplies.<\/span><\/p>\n

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.<\/span><\/p>\n

The Core Problem: Portfolios Are Optimized for Shortlisting, Not Accuracy<\/b><\/h2>\n

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.<\/span><\/p>\n

Three specific distortions recur often enough to plan for. Each one survives a casual review and fails a five-minute check.<\/span><\/p>\n

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<\/span> staff augmentation shops<\/b><\/a> 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.<\/span><\/p>\n

Second, <\/span>white-label development<\/b> 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.<\/span><\/p>\n

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<\/span> red flags in a software development company<\/b><\/a> that usually surface far later in a deal.<\/span><\/p>\n

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

How to Check a Software Company Portfolio: The 5-Step Verification Process<\/b><\/h2>\n

Run these five steps in order. Steps 1\u20133 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.<\/span><\/p>\n

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

    Step 1: Ask for Live Project Links and App Store Listings<\/b><\/h3>\n

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

    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.<\/span><\/p>\n

    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<\/span> vet a mobile app development company<\/b><\/a>. A 2019 app with no release since launch is a different signal than one shipping monthly.<\/span><\/p>\n

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

    Step 2: Check Launch Dates Against the Wayback Machine<\/b><\/h3>\n

    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.<\/span><\/p>\n

    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<\/span> how you select the best IT company<\/b><\/a> from a shortlist.<\/span><\/p>\n

    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.<\/span><\/p>\n

    Step 3: Look for the Same UI Kit Across “Different” Clients<\/b><\/h3>\n

    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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    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<\/span> custom versus template cost gap<\/b><\/a> 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.<\/span><\/p>\n

    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.<\/span><\/p>\n

    Step 4: Ask Which Parts the Agency Actually Built<\/b><\/h3>\n

    Build ownership is the question that collapses the most impressive-looking portfolios. Put it in writing during <\/span>project scoping<\/b>, before the commercial conversation:<\/span><\/p>\n