How to Vet an App Development Agency: Red Flags and the Questions to Ask
If you are commissioning an app, there is a reasonable chance you are doing it for the first and only time, while the agency sitting across from you has run that same meeting several hundred times and has a fairly accurate sense of which parts of its pitch you are unlikely to check. That imbalance is the actual problem here. It also explains why failed builds tend to look very similar once they are over, because the warning signs were usually visible in the first two or three conversations and the buyer did not know they were warning signs.
We read a lot of vendor proposals, and we talk to the people who write them, and the pattern that keeps coming up is that buyers end up assessing the sales experience instead of the delivery record. An account manager who replies to emails within the hour is pleasant to deal with, but that fact tells you very little about whether the code that eventually ships will be maintainable by anybody other than the people who wrote it.
What follows is the vetting process we would run ourselves, which includes eight red flags, ten questions, a method for confirming that a portfolio is real and not decorative, and a reasonably honest comparison of the risks involved in hiring a freelancer as against hiring an agency.
What vetting actually means here
Vetting is the work of confirming, from sources outside the vendor’s own marketing material, that a firm can build the thing you are paying for and then hand it over to you. Three terms come up repeatedly in this area, and each one is worth defining on its own.
Agency red flags are the observable warning signs that appear during the sales process, before you have committed to anything. They are behavioural, not technical, and they cover how a firm scopes a project, what it is willing to put in writing, which of its people it will let you speak to, and which subjects it goes quiet on.
Questions to ask are the specific prompts that force a vendor to describe its process. A useful question has a wrong answer. If any reasonably competent-sounding firm could answer it comfortably, then the question is not doing any work for you.
Portfolio verification is the process of confirming that the work a firm claims does exist in public, was in fact published by the firm claiming it, and is still running. It takes roughly fifteen minutes per project, and it is probably the highest-yield step in the whole exercise. It is the same basic instinct behind most of what gets written on Software Egg: a company says a feature exists, and the only way to know is to go and look for it yourself.
Security is the one area where you do not have to take anybody’s word for anything, because the field has published standards for it. The OWASP Foundation maintains a ranked list of mobile risks, which is currently headed by improper credential usage and inadequate supply chain security. A developer who builds mobile software for a living should be able to discuss that list without preparing for the conversation, and the ones who cannot discuss it are telling you something useful.
There is one more point to make before the list starts. Ranking highly in Google for a phrase such as “app developer Sydney” is a marketing achievement and not a delivery credential. A firm can build a set of city landing pages, acquire some links, and then sit above better builders for years. You can watch this happen in real time: open the top three results for that phrase, then try to find a shipped app behind any of them. Quite often the page ranking first is a location page written for the search engine, with no product attached to it anywhere. Search position is evidence of a marketing budget, and it is sensible to treat it that way.
Eight red flags worth walking away from
1. The price arrives before the questions do
If a firm can quote your app inside a forty-minute call, then it has not scoped anything at all. What it has done is pattern-match your description against a previous project and then apply a multiplier to the result.
Genuine estimation is slow and fairly boring. It involves somebody asking what should happen when a user loses connectivity halfway through a booking, whether your existing systems have an API that can be used, and who is going to own the data at the end. Vendors who do this properly will usually charge for the work, or they will run a short paid discovery stage before they commit to a number, and they will say so early in the conversation.
The softer version of this warning sign is a quote that contains a single figure and no list of assumptions. Ask what the number would do if the assumptions turned out to be wrong. If nobody at the firm can answer that question, then the number was decorative.
2. The portfolio is screenshots and no store listings
Design mock-ups in a slide deck are evidence that a designer was employed at some point. They are not evidence that anything was ever shipped.
Shipping a mobile app is a public act. Apple and Google both require a listing, and that listing carries a developer account name, a version history, an update date, and a support URL that anybody can open. So the test is not how detailed a case study reads; the test is whether the case study points at something you can find in a store and confirm without the vendor’s help. A write-up about “a leading fintech client” gives you nothing to look up, and that is generally why it is written that way.
We are not suggesting that every project covered by a non-disclosure agreement is fiction. We are suggesting that a firm with ten years of work behind it should be able to point at something that is live right now.
3. Nobody will name the people who will do the work
You meet a director and a solutions consultant during the sales process. You sign the contract. The project then lands with two developers you have never spoken to, working in a time zone that nobody mentioned, and the director appears roughly once a fortnight on a status call.
This is not automatically dishonest, and plenty of good agencies staff their projects in exactly this way. The warning sign is a refusal to name names before the contract is signed. Ask who the technical lead is going to be, whether that person is an employee or a contractor, where they are based, and what else they will be working on during your build. A firm with a stable in-house team tends to answer immediately, because the answer is flattering to them.
4. Fixed price, fixed scope, and no mechanism for change
This one is usually sold to the buyer as a benefit, which is what makes it worth watching.
Software scope moves, and it moves because you learn something in week six that you could not reasonably have known in week one. A contract with no change-request process does not prevent that from happening. What it does is turn every change into an argument, and it gives the vendor an incentive to build the cheapest thing that technically satisfies the wording of the specification. That is the usual route to an app that matches its specification and still fails with users.
What you want in place of that is a defined change process, covering how a change gets requested, who prices it, how long approval is expected to take, and what happens to the timeline as a result. Ask to see the template document itself, not a description of how it works.
5. The contract goes quiet on who owns the code
Ask the question directly. Who owns the source code, the repositories, the design files and the various accounts on the day the project finishes?
The answers that should concern you are “we hold the code and licence it to you”, “the app is published under our developer account”, and any version of “we can talk about that at handover”. Handover terms that get negotiated after the money has been spent are negotiated from a weak position. Have the ownership and transfer clause read before you sign, ideally by a lawyer, because that clause is what decides whether you are ever able to change vendors.
6. There is a launch date but no quality assurance story
Ask how the software is going to be tested and then watch what happens. A weak answer describes a person clicking through the app at the end of the build. A stronger answer describes automated tests, a staging environment, device coverage, a defined process for triaging bugs, and a warranty period after launch during which defects are fixed at no additional charge. A team that has strong opinions about something as small as Chrome’s own debugging keyboard shortcuts usually treats testing with the same seriousness.
Testing is usually the first item cut when a fixed-price project starts losing money, which is precisely why you want it named in the contract instead of promised verbally in a meeting. Ask what the warranty period is and ask what it excludes.
7. The references are curated and unreachable
Three complimentary quotes on a website are marketing copy. A reference is a person you actually speak to on the telephone.
Ask for two clients, one of them recent and one of them from a project that either went badly or ran long. The second request is the more useful of the two. Any agency with real history behind it has at least one difficult project, and the way a firm talks about that project is more informative than any of its success stories. A refusal to provide anybody, or an offer to arrange a call that somehow never gets scheduled, is itself an answer.
While you are looking, pay some attention to the wording of the reviews. Testimonials that appear word for word across several different platforms have generally been written once by the vendor and then distributed, and the platforms themselves tend to remove them once they notice.
8. Nobody will say how much of this is AI-generated
This warning sign is relatively new, and it has become one of the more useful ones.
Assisted coding is now normal, and used carefully, it is fine. The risk is a firm quietly using generative tools to produce large volumes of code that no senior engineer has reviewed, and then billing that work as bespoke development. You inherit the maintenance bill for software that nobody on the team fully understands. Catching what a generative tool got wrong takes the same close attention it takes to spot one of VS Code’s own hidden shortcuts and easter eggs: easy to miss, unless somebody is looking for it on purpose.
Ask the question plainly, which means asking where the firm uses AI in its development process, who reviews the output, and what the code review policy actually says. Firms that are doing this responsibly have a written answer ready. Firms that are doing it badly become uncomfortable.
Ten questions to ask before you sign
Each of the questions below has a wrong answer, which is what makes it worth asking.
On track record
- Which three apps in your portfolio are closest to mine, and can I see them live in the store? You are looking for projects of a similar complexity, not a similar industry.
- What is the longest relationship you have with a client, and what have you built for them since the first project? Repeat work is probably the most honest quality signal available to you.
- Tell me about a project that went wrong, and tell me what you changed afterwards. A firm with no such story either has no history or is not being straight with you.
On process and quality
- Who specifically is going to write the code, and are those people employees or contractors? Ask for names and locations.
- How is the work tested, and what does the warranty cover after launch? Push for specifics on device coverage and on how bugs get triaged.
- How do you handle security, and how do you decide what to check for? A reference to a recognised standard is worth more than an assurance that the firm takes security seriously.
- What happens when the scope changes in week six? Ask them to send you the change-request template.
On money and exit
- What exactly does this quote assume, and what would move the price? A vendor who cannot list the assumptions has not built a real estimate.
- Who owns the source code, the repositories, the store accounts and the design files at the end of the project? The answer should already be written into the contract.
- If we part ways at the halfway point, what do I receive and what state will it be in? The response to that question tells you how the firm thinks about the relationship.
How to check that a portfolio is real
This is the part that very few buyers do, and it does not take long.
Start with the store listings. Search for the app name on the App Store and on Google Play, open the listing, and then look at the developer account name, the release history, the date of the most recent update, and the dates on the reviews. An app with a single release from four years ago was built and then abandoned. An app with regular updates and a support URL that points at a live company is a real product that somebody has been maintaining.
The next step is to match the listing against the claim. If the agency says that it built the app, then the developer account on the listing should either be the agency or the client it names, the first release should sit somewhere near the period the agency describes, and the app should still do roughly what the case study says it does. Any of those three that do not line up is worth a direct question, because there are innocent explanations for all of them and the vendor should be able to give you one without hesitating.
The same method works on the client side. Open the client’s own website and look for the app: a company that paid for a build almost always links to it. If a named client has no trace of the product anywhere, either the project was shelved, or the relationship was smaller than the case study implies.
After that, ask for references and then actually telephone them. Ask the reference what the agency was like when something went wrong, whether the estimate held up, and who did the work on a day-to-day basis. Ten minutes on the phone will either contradict or confirm most of what you have been told.
Finally, treat directory badges with a good deal more suspicion than they usually receive. Placement in listing directories is often a paid position and not an earned ranking, and the ranked order can move with what a vendor is paying in a given month. That is straightforward to test for yourself: pull up the same directory category from two different devices, or from a different network or city, and see whether the firms and the order stay the same. Where the list is unstable, you are looking at rotating advertising inventory. Awards and directory rankings are a marketing expense. They are not an audit, and they are certainly not a replacement for opening a store listing and looking at it yourself.
Freelancer, agency, or in-house: which risk are you accepting
There is no universally correct answer to this question. Each of the three options fails differently, so the sensible question to ask is which sort of failure you are able to survive.
A freelancer, or a small two-person shop, is the cheapest route and is often the fastest one for a narrow and well-understood build. You get direct access to the person doing the work, which is genuinely valuable. The risks are concentration and continuity, because one illness, one better offer or one disagreement will stop the project. Design, testing, and infrastructure are usually not included, and there is rarely anybody reviewing the code. For a straightforward internal tool, that can be a reasonable trade. For a consumer app that takes payments, the exposure is real.
An agency costs more and moves through more process. What the additional money buys is redundancy and range, in the form of a designer, several developers, somebody doing quality assurance, a project manager, and a business that carries on existing work when an individual leaves. The risks run in the other direction. You may be handed a junior team while the senior people work on a larger account; you are paying for management overhead, and the firm has more bargaining power than you do in a dispute. Sales conversations for a small template build and for a serious commissioned product tend to start from the same search term, so it is worth being blunt fairly early about which of the two you are actually buying.
Hiring in-house gives you the most control and the highest fixed cost, and it generally only makes sense when software is a permanent part of your business rather than a project with an end date.
Whichever way you decide to go, the contract matters more than the pitch does. If you are a small business signing a vendor’s standard agreement, it is worth knowing that Australian law now bans unfair terms in standard form contracts and applies penalties for breaches, with a term counting as unfair where it creates a significant imbalance, is not reasonably necessary to protect the vendor’s legitimate interests, and would cause you harm if it were enforced. Unilateral variation rights, automatic renewals, and one-sided termination clauses are the ones to read through twice.
Frequently asked questions
What are the biggest red flags in an app development agency?
The main ones are a price quoted before any scoping has taken place, a portfolio of screenshots with no live store listings behind them, a refusal to name the people who will do the work, silence on the question of who owns the source code, no described testing or warranty process, references that never quite materialise, and no clear policy covering where generative AI sits in the development process.
What questions should I ask an app developer before hiring them?
Ask which portfolio projects are closest to yours and then check them in the store; ask who writes the code and whether those people are employed or contracted; ask how testing works and what the warranty covers; ask what the quote assumes and what would move it; ask who owns the code, the repositories and the store accounts; and ask what you receive if the project ends early.
Who owns the code and the intellectual property when an agency builds my app?
Whoever your contract says owns it. That is worth checking and not assuming, because ownership defaults to the creator in Australia, where IP created by a contractor is the property of the contractor unless the contract states otherwise. Written assignment of the copyright in the source code, the design assets, and the repositories should be in the agreement before any work starts.
How do I verify that an agency’s portfolio is genuine?
Find the apps on the App Store and on Google Play, check the developer account name against the agency name, look at the release history and the date of the most recent update, and then cross-check the details in the case study against what the listing actually shows. After that, speak to two referenced clients, including one whose project did not go smoothly.
Is a freelancer riskier than an agency?
They are risky in different ways. A freelancer concentrates all of the delivery risk in one person and will usually exclude design, testing, and ongoing support. An agency spreads that risk across a team and charges you for the overhead involved, although you may not get the senior people you met during the sales process. Match the choice to the consequences of the project stalling.
How long should vetting take?
For a build worth six figures, allow two to three weeks and speak to at least three firms. Most of that time gets spent waiting for references and reading contracts, not sitting in meetings.
What to do with all this
The firms worth hiring are generally the ones that make vetting easy. They name the team, they publish work that you can open in the store, they put ownership and testing into the contract, and they will tell you what they are not good at without being pushed into it.
One Sydney firm that sells into this market is Appello Software, an app development agency established in 2017 with mobile app development in Sydney among its service lines. Two limitations are worth knowing before you call them. It publishes no pricing whatsoever and quotes only after a scoping stage, so you cannot compare its cost against anybody else’s until you have spent time in a sales process. It is also a generalist that sells across a very wide range of industries, so if you need a team that has built nothing but clinical or financial software for the last five years, this is not that team.
Two weeks of this work costs you very little, and it is the only part of the process you fully control. Run the eight warning signs as a filter, take the ten questions into every meeting, and pay attention to any vendor who makes you feel awkward for asking them, because that reaction is itself the answer.
