Set out to hire a mobile app developer and the search results will sell you a shortlist, a cost table, or a pool of people somebody else has already screened. All three quietly assume the hard part is finished, and they hand you a comparison exercise in its place. What you actually have to do is judge one person, or one small group of people, and decide whether they can build the app you have in your head and keep it working afterward.

That matters because of where the accountability lands. A year from now, when a release breaks on a phone model you have never held, or the app stops talking to the server on a Tuesday afternoon, the vendor will have moved on to other accounts and the freelancer will have other clients. You’ll still be there. So the question underneath the whole search is simpler than the pages make it look: on what basis will you know this developer is any good?

We wrote a guide to hiring a mobile app team that ends its checklist with a question it doesn’t answer, “who on your side judges the answers?” This post is that answer, and it comes down to three things you can check yourself without being able to read the code.

We read through the pages competing for this search in September 2026, and they fall into a pattern worth spelling out.

Appinventiv’s guide is the deepest of the set, sixteen sections running from a market overview down to an FAQ. It argues that outsourcing beats hiring in-house, publishes cost tables broken out by app type along with hourly bands by region, and lists contract terms and red flags worth watching for, including code ownership and pricing that looks too good to be real. What all of that gives you is a list of topics to raise. The page never describes what a good answer to any of those topics sounds like, which is the part a buyer without an engineering background actually needs.

Indeed’s page is the one result in the set aimed at hiring an employee instead of a vendor, and it’s built around Indeed’s own candidate database, with sample profiles and an FAQ covering job descriptions and onboarding basics. There are no interview questions on it, no salary data, and no technical evaluation criteria of any kind.

Freelancer.com sells speed and volume, with first bids arriving in about a minute and projects drawing more than a hundred of them, and it settles the evaluation problem by handing it to star ratings and reviews, plus a promise that you pay only when you’re happy with the result. The dev shops make the same move with a bench instead of a crowd: Zazz offers more than 285 developers and a pre-screened shortlist inside 48 hours, on engagement tiers that get cheaper the longer you commit, while Binary Studio offers 160-plus engineers and pitches hiring in weeks instead of months.

Every page on that results list is selling pre-screening, and none of them tells you how to screen. Zazz and Binary Studio say so outright with the 48-hour shortlist and the bench, Freelancer hands the job to aggregate ratings, and Appinventiv and Indeed leave the gap where it is. Trusting somebody else’s screen is a reasonable trade if you’ve actually decided to make it, but you’re still the one who answers for what ships, so it’s worth having your own read on the person before you sign anything.

Ask for a link you can open rather than a deck. A live listing on the App Store or Google Play, under their name or under a client’s name you’re allowed to contact, is the floor. A folder of demo apps that never shipped tells you the person can get something building and running on a simulator, which stopped being a meaningful filter a while ago.

Then go past the screens, because screens are the cheapest thing in the folder to produce and tell you the least. For each app they shipped, ask what it talked to. Was there a server behind it, did they write that server or consume somebody else’s API, and what happened the week the app and the server had to change together?

That last question does more work than it looks like it does. Phones don’t update on your schedule. A month after a release goes out, some real share of your users are still running the version before it, so the server has to keep both of them working at the same time. A developer who has shipped and then maintained an app will have a way of handling that and will usually volunteer it: versioned endpoints, a flag that turns new behavior on once enough installs have caught up, a screen that tells stragglers to update, responses written so an older app ignores fields it doesn’t recognize. Somebody who has only built demos will tell you the app and the server deploy together, because in a demo they always do.

Two more things belong in this pass. Ask why each app was built the way it was, native or cross-platform, and listen for whether they can name what the choice cost them as well as what it bought them, because anyone who has worked both sides can do that without effort while someone who only knows one tool ends up describing the tool instead. And treat portfolio counts and client logos on directory listings as unverified until you check one, which takes about ten minutes: open the listing, find the app in the store, and see whose name is on it. We ran that check across a set of local directory listings and a published top-ten list in two posts, and it’s worth doing yourself on whoever you’re considering.

This is the check that’s hardest to fake, and it costs you about a quarter of an hour. Ask the candidate to pick one real feature from something they shipped and walk you through it end to end: what the user taps, what goes out to the server, what the server does with it, what comes back, what the screen shows while all that is happening, what happens when the phone has no signal, what happens if the request dies halfway through, and what a test for the whole path would check.

You don’t have to evaluate the technical content of the answer. You’re listening for four things.

The first is whether the narration runs all the way through or stalls at the boundary between the app and the server. That boundary is where mobile projects go wrong, and a candidate whose experience stops at the screen tends to go vague exactly there, usually by sliding into the passive voice: the data gets sent, the response comes back.

Second, watch for whether they raise the failure cases before you ask about them. Anyone who has shipped has watched an app fall over in a stadium with no bars, or on a train heading into a tunnel, and they’ll bring it up unprompted because it cost them a weekend once.

Then there’s how specific they get. Real work comes with particulars, like the name of the screen, the reason one call was slow, a number they still remember because they stared at it for a week. If the answer never gets below the general level, it’s usually because there’s nothing more specific behind it.

The last thing to listen for is whether they say what they’d change. Anyone who stayed on to maintain what they built keeps a running list of things they’d do differently and will usually be glad to walk you through it, where somebody who handed the project off at launch tends not to have one at all.

Use the same prompt with everyone you’re considering, so the answers sit side by side and the differences between them come from the candidates rather than from how you asked.

A working app is far cheaper to produce than it was two years ago. An assistant will get a demo building, running, and looking reasonable inside an afternoon, so “here’s an app I made” carries less signal in 2026 than it did when that sentence implied months of work. The distance between somebody who understands what they built and somebody who prompted it into existing has narrowed at the surface, and the surface is what a portfolio shows you.

Asking what the code does won’t separate the two, since anyone can read it back and an assistant will happily explain it again on request. Ask why it’s built that way, and then ask a second why about a harder version of the same problem. If that list screen loads twenty rows, what happens at ten thousand? If two people edit the same record from two phones and one of them is offline, who wins? A borrowed answer thins out on that second question and slides back into describing what the code contains, while an answer that came out of doing the work gets more specific instead, and often turns into a story about the time it went wrong in production.

None of this is an argument against AI-assisted development. We build with these tools every day and have written about how we use them. The thing you’re checking for is whether the person can defend the decisions inside a codebase, since the first real request you make of them will be to change it.

None of this depends on which arrangement you end up in. If you’re interviewing an employee, the walkthrough fits inside the loop you already run. If you’re buying from a vendor, ask to run it with the engineer who will actually be assigned to your account instead of the person on the sales call, and treat a refusal to put you in front of that engineer as an answer in itself. If you’re weighing a freelancer, run the checks against their sample work before you contract anything.

Which arrangement to pick in the first place is its own decision, and we compared freelance, in-house, and an outside team on their own terms. What happens to the code, the store accounts, and the infrastructure once an engagement ends belongs in the contract conversation, and the support obligations that begin the day you launch are worth settling before you sign as well. All of that is about the shape of the deal, though, and none of it tells you anything about the person who’ll be working inside it, which is what the three checks here are for.

Write the walkthrough down before you talk to anybody. Pick the kind of feature you care about most, note the four things you’re listening for, and keep the script identical across candidates. Then take one portfolio link all the way through to a live store listing, and hold everyone you talk to at that bar.

If the honest answer is that nobody on your side can run this evaluation, that’s a narrow, one-time version of the gap a fractional CTO engagement exists to close, and you can borrow that judgment for a single hiring decision without taking on the whole arrangement.

Either way, book an intro call and tell us who you’re considering. We’ll tell you what we’d ask them.