How to Vet an App Development Agency: Red Flags, Verification, and the Questions That Actually Matter
A founder I worked with signed a fixed-price contract for a "simple" marketplace app. The demo looked great. Six months and roughly double the budget later, the build still crashed on older Android phones, the agency could not explain why, and the source code turned out to be half-owned by a subcontractor nobody had told her about. She had done what most buyers do. She looked at a nice portfolio, liked the people on the call, and trusted the quote. None of that told her whether the team could actually ship.
This is not a rare story. In a joint study with the University of Oxford, McKinsey found that large IT projects run, on average, 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. App builds are smaller than the enterprise programs in that dataset, but the pattern rhymes. The gap between a good pitch and a good delivery is where most of your money disappears.
I have sat on both sides of this table, first inside agencies and then advising the clients who hire them. What follows is how I vet a mobile app development company now, in the order I actually do it: read the red flags, verify the portfolio, pressure-test the process, then ask the questions that separate a real shop from a good salesperson.
What Counts as a Red Flag When You Are Hiring a Developer
Agency red flags are the observable warning signs, in a proposal, a portfolio, or a sales conversation, that a development team either cannot deliver what it is promising or is hiding how it works. They are not proof of a bad agency on their own. They are prompts to dig deeper before money changes hands.
Some are loud. A team that will not name a single shipped app, or that dodges a reference request, is telling you something. Others are quiet and matter more: a scope so vague you could drive a truck through it, no mention of testing anywhere in the proposal, an intellectual property clause you have to squint to find. The loud flags scare off amateurs. The quiet ones are what catch experienced buyers, because they only surface after the contract is signed.
Here is the mindset shift that helps. You are not trying to confirm the agency is good. You are trying to find the reason not to hire them, as fast and as cheaply as possible, before it costs you a build. If you go looking for problems and find none after real effort, that is your signal.
Start With the Portfolio, Because That Is Where the Story Gets Polished
Every agency puts its best three projects on the homepage. That is fine. The mistake is treating those case studies as evidence rather than marketing. A portfolio tells you what a team wants you to believe about them. Your job is to check whether the belief holds.
How do you actually evaluate a mobile app developer's portfolio?
Look past the mockups. Rendered screens in a case study prove a designer exists, not that anyone shipped working software. I work through four questions on any portfolio, and they apply just as well to an agency in Sydney or Melbourne as anywhere else:
Is it live? Can you download the app right now from the App Store or Google Play, or is it a concept that never launched?
Is it theirs? Plenty of agencies list apps they touched for two weeks as subcontractors. Ask which parts they built and owned.
Is it recent? A flagship project from 2019 tells you little about the team working there in 2026. People move on.
Is it relevant? A beautiful consumer photo app says almost nothing about whether a team can handle payments, offline sync, or health data compliance.
For the Australian market specifically, ask whether they have shipped for local conditions: integrations with local payment providers, compliance with Australian privacy expectations, and support hours that overlap with your business day. An overseas portfolio can be excellent and still leave you calling a support line at 3 am.
What is portfolio verification, and how do you do it?
Portfolio verification is the process of independently confirming that the apps an agency claims as its work are real, still live, and genuinely built by that team, rather than taking the case study at face value. It is the single highest-value hour you will spend during vetting.
Do it in three passes. First, find each claimed app on the App Store or Google Play yourself, rather than clicking the agency's own link. Read the reviews, check the last update date, and note the listed developer account. Apple's own App Store Review Guidelines require that a shipped app be complete and functional, with no placeholders or obvious crashes, so an app that actually cleared review and has been maintained is a meaningful signal that a team can finish things rather than only start them. Second, ask the agency directly which parts of each app they built, and whether they can connect you with the client. Third, and this is the step people skip, actually take the reference call.
On the reference call, do not ask "Were you happy?" Everyone says yes. Ask what went wrong and how the team handled it, whether the final cost matched the estimate, who owned the code at the end, and whether they would hire them again for something harder. The answers to the uncomfortable questions are the ones that predict your experience.
The QA and Process Question Most Buyers Skip
Here is the part that separates teams that ship from teams that demo. Almost nobody asks about it during vetting, and it is the strongest predictor of whether your app will survive contact with real users.
Ask any agency to walk you through what happens between "code is written" and "app is in the store." A mature shop has a real answer: how they test across devices and operating system versions, how they track and triage bugs, how they handle a change request mid-build without the whole timeline collapsing, and how they support the app after launch. A weaker one waves at "we test thoroughly" and moves on. Thoroughness is not a process. It is an adjective.
Mobile makes this harder than the web because of fragmentation. An Android build has to behave across dozens of screen sizes, chipsets, and OS versions, and iOS releases move fast enough that an app healthy in June can break in September. Security matters too, especially in finance, health, or anything touching payments. There is an industry reference standard for this, the OWASP Mobile Application Security Verification Standard, and a team that has never heard of it is a team you probably do not want handling sensitive data. You do not need to memorise it. You just need to hear whether structured testing is part of how they work, or something they do when there is time left over. There usually is not time left over.
This is also where a documented process beats a talented individual. A handful of specialist providers run scoping, testing, and post-launch support as a defined service rather than an afterthought. One of the Sydney firms that operates this way is Appello Software, which offers custom software and mobile app development in Sydney end-to-end: strategy and cost estimation up front, multi-device testing, deployment, and post-launch change-request management across iOS, Android, cross-platform, and AR builds for sectors like finance, healthcare, and logistics. Whether that specific fit is right for your project or not, the shape of the offer is the thing to look for. A defined process with named stages beats a promise to figure it out as they go.
Freelancer or Agency? It Depends on What Can Go Wrong
The freelancer-versus-agency debate gets treated like a moral question. It is not. It is a risk-tolerance question, and the honest answer is that each fails differently.
A good freelance developer is cheaper, faster to start, and often more talented per dollar than the average agency mid-level engineer. The failure mode is concentration. One person gets sick, takes another contract, or simply disappears, and your project stops. There is rarely QA beyond the developer's own eyes, no designer, no project manager buffering scope creep, and no backup if the relationship sours. For a prototype, a small internal tool, or a well-defined feature, that trade can be perfectly sensible.
An agency costs more and moves more slowly to start because you are paying for redundancy: multiple engineers, a designer, a tester, a project manager, and continuity if someone leaves. The failure mode is the opposite. You can pay agency prices for junior work quietly delegated behind a senior salesperson, get lost as a small account, or drown in a process that bills hours without shipping features. The mitigation is the same vetting discipline this whole piece is about. Verify who actually does the work, not who shows up to the pitch.
A rough rule I use: if the cost of the project failing is small and you can afford to restart, a vetted freelancer is fine. If failure means a missed market window, a compliance problem, or a product your business depends on, pay for the redundancy and vet the agency hard.
The Red Flags Checklist
Run a candidate against this before you get emotionally invested in the pitch. Any single item is a conversation, not a disqualification. Three or more, and I walk.
No portfolio depth. Two or three case studies with no downloadable, still-live apps behind them. If you cannot install their work, treat the portfolio as fiction until proven otherwise.
Vague scope. A proposal that describes what the app will do in marketing language but never lists specific features, screens, deliverables, or acceptance criteria. Vague scope is how "simple" projects triple in price.
No QA process. Testing is not mentioned, or is a single line, or gets pushed onto you as "user acceptance." A team without a real testing process is asking you to be the tester.
Unclear IP and ownership terms. You cannot find, in plain language, a clause stating that you own the source code and assets on final payment. If it is not written down, assume you do not own it.
Estimates with no assumptions. A confident fixed price with no list of what it assumes about scope, integrations, and change. That confidence is either inexperience or a setup for change-order billing later.
A salesperson who will not let you talk to engineers. If the people who will build the app are hidden until after you sign, you are buying a pitch, not a team.
Pressure and urgency. "This price is only good this week." Good agencies have pipelines. Manufactured urgency is a tell.
The Questions to Ask Before You Sign
Questions to ask are the direct, specific queries you put to an agency during vetting to expose how they scope, build, test, own, and support the work, before you are financially committed. Vague questions get rehearsed answers. Specific ones force a real one.
Ask these, and listen for whether the answer is concrete or a slogan:
Who, by name and seniority, will actually write the code, and will that change after we sign?
Can you show me two live apps you built that are similar to mine, and connect me with those clients?
What is your testing process across devices and OS versions, and who does it?
How do you estimate cost and timeline, and what happens to both when scope changes mid-project?
Who owns the source code, the design files, and the app store accounts at the end? Get this in writing.
What does support look like after launch, and what does it cost?
What is the last project that went badly for you, and what did you change afterward?
That last one is my favourite. An agency that cannot name a project that went sideways is either lying or has not shipped enough to have scars. The good ones answer it honestly because they have learned something you are about to benefit from.
On IP specifically, do not let it slide to the contract's fine print. In a custom build, you generally want a clear written assignment of the source code, assets, and accounts to you on final payment. Agencies sometimes retain rights to reusable components or frameworks they built before your project, which can be reasonable, but the app itself and its custom code should be yours, and it should say so in the words of the agreement, not in a verbal reassurance.
What Actually Separates Top iOS and Android Developers
Once an agency clears the red flags and the portfolio checks out, you are comparing genuinely capable teams. The criteria that decide the best from the merely competent are less about tools and more about judgment.
Platform depth, rather than mere presence, in both stores. A top iOS or Android team understands the platform's native patterns, its human interface expectations, its performance constraints, and its review process, rather than shipping one generic build wrapped for both stores.
Architecture that survives version two. Good developers build so the app can grow. Weaker ones build so the demo works, and every new feature after that fights the foundation.
A real testing and release discipline. Automated where it counts, manual across real devices, with a repeatable path from code to store.
Communication under pressure. The best teams tell you bad news early. The rest tell you everything is fine until the deadline arrives.
Post-launch commitment. An app is not done at launch. It needs OS update maintenance, bug fixes, and iteration. Teams that treat launch as the finish line leave you stranded three months in.
When you compare finalists, weigh these over price. The difference between a cheap build and a good one is rarely visible at launch. It shows up six months later, whether you are iterating on a solid product or paying someone else to untangle the first team's shortcuts.
FAQ
How much should I trust online reviews and rating platforms?
Use them as a starting point, not a verdict. Reviews on directories and rating platforms can be genuine, curated, or incentivised, and it is hard to tell which from the outside. Treat a strong review profile as a reason to shortlist, then do your own portfolio verification and reference calls. The independent check you run yourself is worth more than any badge or star count.
Is a fixed-price or time-and-materials contract safer?
Neither is safer by default; they move the risk to different places. Fixed price protects your budget but punishes change, so it works best when the scope is genuinely well defined and unlikely to shift. Time and materials adapts to change but requires trust and active oversight, so it suits evolving products where you can stay involved. The real protection is a detailed scope document, either way, plus a written process for how changes get priced and approved.
What is a reasonable budget for a custom mobile app?
There is no honest single number, because a custom app can mean a two-screen utility or a regulated platform with payments and real-time sync. Be suspicious of any quote given before the scope is understood. A credible agency will want a scoping or discovery conversation first, and will give you a range with stated assumptions rather than a precise figure pulled from thin air.
How long should vetting take?
Longer than most people give it, and far less than a failed build costs. Budget a couple of weeks for shortlisting, portfolio verification, reference calls, and a scoping conversation with your top two. Rushing this step to save days routinely costs months later. The vetting is cheap. The wrong agency is not.
Key Takeaways
A good pitch predicts nothing. Verify the portfolio yourself by finding live apps on the App Store and Google Play and calling real references.
The quiet red flags cost the most: vague scope, no QA process, and unclear IP ownership. Get code ownership in writing.
Ask about the process between "code written" and "app in the store." A documented testing and release discipline separates teams that ship from teams that demo.
Freelancer versus agency is a risk decision, not a moral one. Match the redundancy you pay for to the cost of the project failing.
When comparing capable finalists, consider weight architecture, testing discipline, and post-launch commitment over the headline price.
Vetting an app development agency is not about finding the perfect team. It is about removing the ones that will hurt you, methodically, before you are committed. The cost of an extra week of due diligence is a few conversations and a couple of app downloads. The cost of skipping it is the story I opened with, and I have heard that story far too many times to think it was bad luck.
