Picture this. You have paid 70% of the budget for your app. Every Friday the agency sends screenshots and a short video. It all looks good. But you have never installed the app on your own phone, you do not have the code, and when you ask for a test build the answer is "next week, once it is stable".
Nothing has gone visibly wrong yet, and that is the problem. When outsourcing app development, most of the warning signs appear early and quietly, long before a missed deadline. Below are the ones worth acting on, grouped by the stage where you are most likely to see them, with what to do about each.
Before you commit to outsourcing app development
A firm price for a vague brief
If you sent two paragraphs and got back a fixed quote within hours, with no questions, the vendor is pricing a guess. Either the number will grow through change requests, or corners will be cut to hold it. A careful team asks what happens when a booking is cancelled, who the admins are and which payment methods you need before it commits to a price.
Protect yourself: ask for the assumptions and exclusions in writing. If there are none, the quote is not really comparable with others.
Nothing live to show
Mockups on a design gallery are not shipped apps. Ask to install something the team built and ask which parts they did themselves. You can see what we have delivered in our project portfolio, and it is fair to question us about any of it the same way.
Payments weighted to the start
Fifty percent upfront and fifty percent on delivery puts all the risk on you. If the relationship breaks down halfway, you have paid for half an app you may not be able to use.
A contract that says nothing about ownership
If the contract does not assign the code to you, the default rules in many countries leave it with the people who wrote it. Our article on who owns the code and what a handover should include explains what the clause should say.
During the build
You cannot install the app
Both stores provide ways to share test builds with a small group before release: TestFlight for iOS and testing tracks in Google Play Console. There is no technical reason you cannot have a build on your phone within the first few weeks. Screenshots and screen recordings can hide slow screens, crashes and features that only work on the developer's device.
"You will get the code at the end"
The repository should live in your account from week one, with the vendor's developers added to it. Holding the code back until final payment is a bargaining chip for the vendor, not a technical necessity.
Nobody tests except the developer
Developers test that their code does what they meant it to do. Someone else needs to test whether it does what users will actually try. Ask who writes test cases, which physical devices the app is checked on, and whether you can see the bug tracker. If there is no separate testing at all, budget for independent QA and testing before launch, whoever provides it.
Changes agreed on calls and never written down
Verbal agreements feel efficient until the invoice arrives. Every change should produce a short written note: what changes, what it costs in time or money, and your approval.
New names on the team without warning
People move between projects. That is normal. It becomes a red flag when you find out by accident, and the new developer is learning your codebase on your budget without a handover.
At launch
The app is published under the vendor's developer account
This is one of the most expensive red flags to fix later. The store account that publishes the app controls the listing, the reviews, the signing configuration and often the revenue. Moving an app afterward is possible but comes with conditions. Google's app transfer process needs registration details from both accounts, and payout and earnings reports do not move with the app. Apple requires, among other things, that the app has a released version and nothing waiting for review.
Protect yourself: create your own Google Play and Apple developer accounts early. If you publish as a company, both stores ask for a D-U-N-S number. Google says getting one can take up to 30 days, and Apple's enrollment help says to allow up to five business days from Dun & Bradstreet plus two more for Apple to receive it. It is free, but it is not quick, so start in the first month of the build.
Offers to "bypass" store rules
New personal Google Play accounts have to run a closed test before they can publish to production; our article on Google Play's closed testing rule explains how to plan for it honestly. Some vendors offer to skip it using an older account they have bought. Do not accept. Google's Play Console requirements prohibit buying, leasing and selling developer accounts, and an app published that way can lose its listing along with the account.
After launch
Watch for three things in the first month:
- No crash reporting or analytics. If nobody can tell you how many sessions crashed yesterday, problems will reach you through one-star ratings first.
- Undefined support. "We will help if anything comes up" is not a support arrangement. You want a written warranty period for defects, response times, and a rate for changes after that.
- Bugs reopened as new work. A defect in something the vendor delivered is not a change request.
Fixing a front-loaded payment plan
Say a fitness studio is quoted $30,000 for a class booking app: 50% upfront, 50% on delivery, 14 weeks. Here is how the same money could be tied to things the studio can check:
- 15% ($4,500) for a clickable prototype of the main screens, reviewed with two instructors.
- 25% ($7,500) for sign-up, the class timetable and booking, installed on the owner's phone through a test track.
- 25% ($7,500) for payments, memberships and the staff admin panel, working on a staging server.
- 20% ($6,000) for store submission from the studio's own developer accounts, with the repository and credentials handed over.
- 15% ($4,500) after 30 days live, once reported defects are fixed.
The vendor's total is unchanged. What changes is that each payment follows work the studio has seen running, no single payment is more than a quarter of the budget, and the last one rewards fixing problems rather than just shipping.
Not every warning sign is a red flag
Some things feel uncomfortable but are usually good news. A team that asks a lot of questions before quoting, that refuses a fixed price until the scope is clearer, that recommends a short paid discovery phase, or that tells you to drop a feature from version one is showing you how it will protect your budget later. Be more wary of a team that finds everything easy.
If you already have a project underway, check three things this week: can you install the latest build, do you have access to the repository, and whose name are the store accounts in. Any "no" is worth fixing before the next payment.
If something on this list has already happened to you and you want a second opinion on where the project stands, tell us what you have. We will look at the build, the code and the accounts and tell you what is worth keeping and what is not.
