What a Mobile Vendor's Past Work Actually Tells You Before You Hire Them

Every mobile development vendor leads their pitch with a portfolio. A grid of app screenshots, a list of client names, a handful of case studies. It is the most common form of proof a vendor offers — and the most commonly misread.

A portfolio tells you what a vendor has shipped. It does not tell you whether they shipped on time, at the quality they committed to, with the communication process you will depend on, or with the team that is actually available to work on your engagement. Those are the things that predict whether the relationship will work.

What a portfolio can tell you

Industry experience. A vendor that has built a HIPAA-compliant healthcare app understands the compliance constraints, the App Store medical content policies, and the reliability requirements specific to clinical contexts. A vendor that has shipped a field service app for a logistics company understands offline data sync, GPS accuracy requirements, and what happens when a field technician's phone runs low on battery in a remote location. Industry experience shortens the ramp-up and reduces the risk of the vendor underestimating complexity that is specific to your sector.

Platform depth. Shipping five apps on iOS is evidence of iOS experience. Shipping across iOS and Android with a consistent quality bar is evidence of cross-platform depth. A vendor who has only shipped on one platform and is now bidding for a dual-platform engagement is taking on new complexity on your time.

Scale. There is a meaningful difference between a vendor that has shipped an app to 100,000 users and one that has shipped to 5 million. The performance requirements, the infrastructure, the QA process, and the monitoring requirements are all different. A portfolio that shows apps at the scale you need gives you confidence the vendor has solved the problems that come with that scale.

Complexity match. An app that integrates with a legacy ERP, handles payments across multiple providers, and runs offline in low-connectivity environments is genuinely complex. A vendor that has shipped that kind of app has a different capability profile than one that has built simpler consumer apps with standard API integrations. Match the complexity of the portfolio work to the complexity of what you need to build.

What it cannot tell you

A portfolio is a collection of outcomes. It does not tell you what the process looked like to produce those outcomes. An app that looks polished may have shipped six months late, required three team changes, and consumed twice the budget originally scoped. None of that is visible from the app itself or from a case study that the vendor wrote.

Specifically, a portfolio cannot tell you:

Whether the vendor hit the timelines they originally committed to. Whether the budget ran over the original estimate, and by how much. Whether the client would use the vendor again. Who specifically built the app, and whether those people are available for your engagement. How the vendor communicated when something went wrong. What the quality looked like over the first six months of the engagement, not just at launch.

These are the variables that predict your experience. None of them are in the portfolio.

Five questions that close the gap

Question 1: For the most relevant case study in your portfolio, did you hit the original timeline and budget?

This is the single question that surfaces more information than any other. A vendor that hit the timeline and budget will say so directly and can point to specifics. A vendor that did not will either hedge, explain the overrun, or pivot to what the outcome looked like rather than how the delivery ran. The explanation may be legitimate — genuine scope changes, third-party delays outside the vendor's control. The way the vendor handles the question tells you as much as the answer.

Question 2: Can I speak directly to the client from that engagement?

The reference call is the only way to get an unfiltered view of how the vendor operates. Ask for a direct phone call, not a written testimonial. The questions to ask the reference: did the vendor hit the committed timeline, how did they communicate when something went wrong, what would they do differently, and would they use the vendor again on a project of similar complexity.

Question 3: Who specifically built the apps in this portfolio, and are those people available to work on my engagement?

Vendor portfolios are built by teams. The team that built the most impressive work in a vendor's portfolio may not be the team available for your project. Ask for names and roles, and ask whether those specific people are currently available or engaged on other projects. A vendor that cannot tell you this, or that hedges on availability, is not confirming that you are getting the capability the portfolio implies.

Question 4: What was the crash-free session rate at launch for the most complex app in your portfolio?

This is a technical metric, but the question is not a technical one. You are not asking how it was achieved — you are asking whether the vendor tracks quality outcomes and can produce them on request. A vendor that has shipped high-quality apps knows this number. The target for a well-built app is 99.5 percent or higher. A vendor that does not track it or cannot recall it for a recent engagement has not built quality measurement into their process.

Question 5: How long did the core team stay on that engagement?

Team continuity is one of the most underweighted factors in vendor selection and one of the most consequential. A vendor that changes teams frequently — and does not disclose this during the sales process — is offering less than the portfolio implies. Ask specifically: were the same engineers on the project from start to finish, and if not, what happened?

How to read the case study itself

A well-written vendor case study describes a problem, what was built to solve it, and the measurable outcome. The outcome should be in numbers: crash-free rate, release cadence, user engagement change, revenue impact. Outcomes described in qualitative language only — "significantly improved," "much faster," "users loved it" — are not outcomes. They are impressions.

Ask what the numbers were before the engagement and what they were after. A vendor that cannot supply before and after numbers for the outcomes they are claiming either did not measure them or the improvement was not as significant as the case study implies.

Also pay attention to what is not in the case study. A case study that describes the technical complexity in detail but says nothing about the timeline, the budget, or the client's satisfaction with the process is a case study written to highlight capability and obscure delivery. Both matter.

What to do when there is no portfolio match

Sometimes the vendor you are evaluating does not have a case study in your specific industry or at your specific scale. This does not disqualify them. What it means is that the capability evidence has to come from a different source: from the questions above applied to adjacent work, from the reference call, and from the vendor's assessment of the risks specific to your engagement.

Ask the vendor directly: "You have not built in our specific sector before. What do you think the complexity we are adding is, and how would you address it?" A vendor that can give a specific, honest answer to that question — naming what they would need to learn and how they would approach it — is more credible than a vendor that has tangentially relevant work but cannot think clearly about what is different about your problem.

The absence of a perfect portfolio match is a manageable gap. The absence of a process to think clearly about risk is not.