We’re an Indian studio, so read this knowing where it comes from. Some of the worst codebases we’ve seen were built offshore. Others were built by agencies a short drive from the client’s office. Geography isn’t the problem. Certain habits are, and the offshore app development agency red flags below show up early enough that you can walk away before you’ve paid much.
We’ve split them by stage: the pitch, the contract and the first few weeks of work. At the end there’s a short list of things that look worrying but usually aren’t.
Offshore app development agency red flags in the sales conversation
- A detailed quote within a day, with almost no questions. Nobody can price an app they don’t understand. If you got a number before anyone asked about user roles, payments or offline use, the number was a guess, and the agency plans to recover the difference later.
- You never speak to a developer. Sales and account managers are normal. But before you sign, you should talk to the person who’ll lead the technical work, and they should be able to explain how they’d build your hardest feature. At orithLabs the people who scope the work write the code, so this one is easy for us, but plenty of good larger agencies manage it too.
- A portfolio you can’t verify. Ask for apps in the stores. Then check the developer name on the store listing, download the app and use it. Plenty of portfolios are full of designs that never shipped or apps that were built by a previous team.
- Yes to everything. An agency that agrees every feature is simple and every deadline is fine is telling you they haven’t thought about it. Good teams push back: “that’s two weeks on its own”, “Apple will probably reject that flow”, “do you need this before launch?”
- A price far below everyone else for the same scope. Rates do vary a lot, between countries and inside India itself. But if one quote is a fraction of the others, either the scope was read differently or the team is very junior. Ask which.
Red flags in the contract
- Code in their repository, delivered at the end. You should own the repository from the first commit. “We’ll hand over everything on completion” means you have nothing if things go wrong at milestone two.
- Store or cloud accounts in their name. Moving a published app between developer accounts is possible but needs the current account holder to start it. Don’t make your launch depend on their goodwill.
- No IP assignment clause, or one that only transfers ownership after the final payment of the entire project.
- A large payment upfront. A modest advance is reasonable. Half the budget before you’ve seen a screen isn’t.
- No exclusions and no change request process. This is how a fixed price stops being fixed.
- Milestones defined by dates or percentages instead of things you can test.
Red flags once work starts
- No build for weeks. By the end of the first build milestone you should be installing something on your own phone through TestFlight or a Play testing track, or clicking around a staging site. “It’s coming together nicely” isn’t a build.
- The team changes quietly. The senior engineer from the sales call stops appearing, and new names show up in commits. Some rotation is normal at larger agencies. It should be announced, not discovered.
- Progress reported as percentages. “Backend 80% complete” can’t be checked. Features you can test can.
- Everything goes through one account manager and technical questions take days to answer, or come back answered vaguely.
- Defensiveness about code review. If you ask a friend or a consultant to look at the repository and the agency resists, ask why.
- Sloppy handling of secrets. Production database passwords pasted into chat, API keys committed to the repository, one shared login for the whole team. This tells you how they’ll treat your users’ data.
Things that look like red flags but usually aren’t
Being fair to our side of the world, a few complaints we hear are less important than they seem:
- The time zone itself. India is ahead of the UK by four and a half or five and a half hours and ahead of the UAE by an hour and a half; the US is harder, but two or three hours of overlap a day is plenty if the written communication is good. Bad agencies blame the time zone for slow replies. Good ones use it to have a build ready when you wake up.
- Formal or slightly unusual English. Clear and polished aren’t the same thing. Judge whether they understood your requirements, not their phrasing.
- Lots of questions and pushback on scope. Annoying in week one, valuable in month three.
- Asking for an advance. Reasonable, as long as it’s small and tied to a first deliverable.
If you’re comparing agencies right now, the most useful thing you can do is write a clear scope and send the same document to everyone. The red flags show up much faster when everyone’s answering the same question. That scoping step is what our product strategy work covers, and orithLabs is happy to do it even if another team ends up building the app.