Red Flags When Hiring a Developer or Agency
Practice4 minInnovialabs editorial team
In short
The main red flags are a suspiciously low or instant quote, no written scope, refusing to share code and access, vague timelines and full prepayment. Each has a simple defense: written agreements and payment tied to results.
In short: what to watch for
An unreliable vendor is rarely given away by a single detail. It is usually a combination: promises without questions, reluctance to put things in writing, and control over your code. Below are the main signals and what to do instead of agreeing.
1. An unrealistic quote
Signal: the price is far below the others, or the quote comes instantly without a single clarifying question.
Why it is bad: the vendor either did not understand the task or plans to make up the budget through "extra work".
What to do: ask for a breakdown by feature and a list of assumptions. Compare what exactly each candidate includes.
2. No written scope
Signal: "Let's just start and figure it out as we go", a contract with no feature appendix.
Why it is bad: at the end of the project there is nothing to prove what was promised.
What to do: document the scope and acceptance criteria, at least for the first stage. Changes go through written amendments.
3. Refusing code access
Signal: the code lives only with the vendor, access comes "after full payment" or "is not allowed".
Why it is bad: you cannot check progress or quality, and switching vendors becomes nearly impossible.
What to do: agree that the repository is created on your account or that you get access from day one. Code ownership goes in the contract.
4. Vague timelines
Signal: "A couple of months or so", with no stages or intermediate results.
Why it is bad: you cannot tell whether the project is on track until it is too late.
What to do: split the project into stages, each with a concrete deliverable and a demo date.
5. Prepayment for the whole project
Signal: a demand to pay everything or most of it upfront.
Why it is bad: the vendor loses the incentive to keep deadlines and quality.
What to do: pay by stages, tied to accepted results.
6. Accounts registered to the vendor
Signal: the domain, server, App Store and Google Play accounts and payment systems are registered in the vendor's name.
Why it is bad: your business depends on someone else's accounts.
What to do: all key accounts belong to your company; the vendor gets access as a member.
7. No questions for you
Signal: the vendor agrees with everything and clarifies nothing.
Why it is bad: a good team always asks about users, scenarios and constraints — you cannot build a quality product without that.
What to do: notice which candidates suggest alternatives and point out risks.
8. No way to talk to past clients
Signal: there is a portfolio, but client contacts are "confidential" and projects cannot be opened.
What to do: ask for at least one live project you can check, or a conversation with a client.
9. Silence about testing and support
Signal: "How do you test?" gets a vague answer; post-launch support is never discussed.
What to do: put a warranty period and support terms in the contract.
Summary table
| Signal | Defense |
|---|---|
| Price with no breakdown | Feature breakdown and assumptions |
| No scope | Written spec and acceptance criteria |
| Code only with the vendor | Your repository from day one |
| Vague timelines | Stages with demos |
| Full prepayment | Payment for accepted stages |
| Accounts in vendor's name | Accounts in your company's name |