Almost everyone picks an app developer on first impression: a tidy website, a few screenshots with perfect drop shadows, and a grand sentence about digital transformation. Those screens tell you nothing about whether the team can launch, maintain, and grow a real product. Knowing how to evaluate an app developer portfolio is a skill you can learn in an afternoon, and it saves you months on a project with the wrong partner. Here are the six checks we run when we look at another studio’s work, written so you do not need to be technical to use them.
What to decide before you open a single project
Before you open anyone’s portfolio, be clear about what you are looking for. A portfolio is not a beauty contest. It is evidence that the developer has solved problems like yours and carried them all the way to the store. If you have not defined your own project yet, you will struggle to judge whether what you are seeing is relevant.
Turn up with three things settled: the type of app you want (booking, marketplace, internal tool, health), the sector you operate in, and a rough budget range. If your budget is still a guess, work through how to scope an app project first, because judging a portfolio without knowing your own constraints is like viewing houses with no idea what you can spend.
How to evaluate an app developer portfolio in six steps
The short version: check the apps exist and are live, look for projects like yours, judge the depth and not just the design, confirm who actually did the work, read the real reviews and downloads, and ask to speak to a past client. If a portfolio clears those six filters, you are looking at a serious developer. Let us take them one at a time.
Step 1: check the apps are live and published
The first filter removes half your candidates. Take each app in the portfolio and find it yourself on the App Store and Google Play. Do not trust the screenshots. Plenty of agencies show Figma prototypes, projects that never shipped, or apps that have since been pulled from the stores.
If the app is live, look at the date of the last update. An app untouched for two years usually means the client walked away or the project died. An app updated every few weeks signals a healthy relationship and a product in real use. That tells you more about the developer than any slogan on their homepage.
Note how many of the portfolio apps are still available. If only three of ten projects are findable in the stores, that ratio is data, not coincidence.
Step 2: look for projects like yours
A developer who has built ten e-commerce apps is not automatically good for your medical appointment app. Relevance matters more than volume. When you evaluate an app developer portfolio, look for projects that share at least one of three things with yours: the sector, the type of feature, or the technical complexity.
If you want an app with payments, booking, and notifications, check they have built those pieces before. Payment integrations with Stripe or GoCardless, geolocation, and offline mode all carry traps you only learn by doing them. A developer who has already solved them will hit you with fewer mid-project surprises, and fewer surprises means fewer line items added to your quote.
Do not be dazzled by big-brand logos if the work done for them looks nothing like yours. A corporate landing page for a bank does not prove a team can launch your product from scratch.
Step 3: judge the depth, not just the pretty screens
This is where design agencies separate from product agencies. A good case study does not show five screens, it tells a story: what the client’s problem was, what they decided to build, what they left out, and what result they got. If a project only shows images with no context, you are being sold aesthetics, not judgement.
Look for numbers in the case studies. “We cut booking time by 40 percent” or “the app processes 3,000 orders a month” is worth far more than “we created a memorable experience”. If the developer reports no results, it might be client confidentiality, but it might be that there were none. Ask directly.
Notice too whether they explain the hard decisions. The best developers will tell you what they cut from the first version and why. That honesty about scope is exactly what you want from whoever manages your budget. If you want to understand how that scope gets defined in the first place, how to write a brief for your UK app developer shows what you should see reflected in their case studies.
Step 4: confirm who actually did the work
Almost everyone skips this step, and it is one of the most important. Many agencies show portfolio projects they subcontracted to freelancers or to a team in another country. The design might be theirs, but the build was done by people who have since gone. If you hire expecting that standard and get assigned a different team, the result will not match the portfolio.
Ask plainly about each project that interests you: who designed it, who built it, and whether those people are still at the company. An honest developer will tell you what they did in house and what they outsourced. One that gets twitchy at this question is telling you something.
Confirm their real role too. Building an entire app is not the same as redesigning the home screen of an app that already existed. Both are legitimate work, but only one proves they can carry a product end to end. If your build genuinely needs ongoing technical leadership rather than a fixed project team, it is worth knowing when a fractional CTO instead of a studio is the better answer.
Step 5: read the real reviews and downloads
The stores are a source of truth the developer does not control. When you find their published apps, read the user reviews and look at the average rating. An app with 4.6 stars and replies from the team to complaints speaks of a product that is cared for. An app with 2.1 stars and reviews moaning about constant crashes speaks of something else.
The download or review count helps too, with caveats. A niche internal tool will have few downloads by design, so do not penalise low numbers without context. What you want is coherence: traction that fits the type of product.
Pay attention to how the developer or client answers negative reviews. The way someone handles public criticism says a lot about who is behind the product, and by extension how they will treat you when something goes wrong.
Step 6: ask to speak to a past client
The last filter is the most revealing and the one fewest people dare to ask for. A developer confident in their work will put you in touch with a past client without fuss. One that makes excuses to avoid it is saving you the trouble of finding out later.
When you speak to that reference, do not ask whether they were happy, because almost everyone says yes. Ask the concrete things: whether deadlines held, whether the final budget resembled the first one, how they handled scope changes, and above all what happened after launch. App maintenance runs around 8 to 15 percent of the build cost a year, and how the developer behaved in that phase tells you whether they build to last or build to invoice and disappear.
How to know you evaluated the portfolio well
You have done a good job when you can answer three questions about any shortlisted developer. First: have they built something like what I need, and is it still alive in the stores? Second: did they do the work themselves or subcontract it? Third: would a past client recommend them with specific detail, not vague praise?
If you can answer all three with confidence, you are no longer choosing on first impression. You are choosing on evidence. That is the difference between a project that goes well and one that becomes an expensive invoice and an app nobody uses.
What to do next
Evaluating an app developer portfolio is not distrust, it is doing your job as a founder before you sign. The six steps take less than an afternoon and save you months on a project with the wrong partner. Once you have two or three finalists who clear every filter, ask them all to quote against the same brief so you are comparing like for like.
If you want to see how we present our own work and get an honest read on your idea, send us your project brief. We will tell you plainly whether it fits what we do, and sometimes the answer is the names of three other people you should talk to instead.
.webp)
.webp)
