A founder forwarded me a proposal last month and asked, quite simply, whether it looked alright. It was twelve pages, nicely designed, with a logo wall and a five-figure number at the bottom. On the surface it looked completely professional. By the third page I had counted three things that would have worried me if I were the one signing. That is the thing about app developer red flags. They rarely announce themselves. They sit inside a pitch that looks polished, and you only notice them later, usually after the money has gone out. So here are the five I see most often, why each one matters, and the question that pulls the truth out in the room.
Red flag one: a fixed price before they understand the problem
The fastest way to spot a shaky app developer is a confident quote that arrives before anyone has asked what you are actually building. If a studio gives you a precise number after a single call and a glance at your Figma, they are not pricing your product. They are pricing their assumption of your product, and the gap between those two things is where every painful change request lives.
A real quote follows real questions. Who is this for, what is the hardest part, what has to be true on launch day, what can wait until version two. When those questions do not come, the number on the page is a guess wearing a suit. I would far rather a developer say “here is a range, and here is what would move us up or down inside it” than hand me false precision I will end up paying to correct.
Red flag two: no questions about your users
Watch what a developer is curious about. If every question is about screens, features, and timelines, and not one is about the people who will use the app, you are talking to a builder rather than a partner. The best teams want to know who has the problem, how badly, and what those people do today instead. That is not consultant theatre. It is the difference between building the right thing and building the thing you were handed.
I have learned this one the hard way from the other side. Early on we took briefs at face value, built exactly what was drawn, and watched perfectly working products meet real users for the first time after launch. Now, when a developer skips the user entirely, I read it as a sign they will build whatever you say and leave you to find out the cost in the open market. A good way to test for this before you ever get to a pitch is to write a brief that puts the user first, which is exactly what a strong app developer brief is for.
Red flag three: the team that pitches is not the team that builds
This is the quietest and most expensive one. A senior, charming lead runs the pitch, wins your trust, and then disappears the moment the contract is signed, replaced by a rotating cast of juniors you never met. Your project becomes a training ground, and you are paying senior rates for it.
Ask directly: who, by name, will write my code, and will I speak to them every week. A studio that builds with its own people will answer without flinching. One that subcontracts to whoever is cheapest that month will get vague, talk about “our delivery network”, and avoid naming anyone. You are not being difficult by asking. You are protecting yourself from a bait and switch that is common enough to have its own rhythm. If you want to pressure-test the people rather than the pitch, looking closely at how they talk about past work tells you a lot, which is why it helps to know how to evaluate an app developer portfolio properly.
Red flag four: they agree with everything you say
Enthusiasm is pleasant. Total agreement is a warning. If you propose ten features and the developer nods at all ten, they are either not listening or not willing to risk the sale by telling you something you do not want to hear. Either way you lose, because the most valuable thing a good studio gives you in the first month is a shorter list than the one you walked in with.
The developers worth hiring push back. They tell you which feature is carrying the product and which three are quietly going to eat half the budget for almost no return. They are comfortable saying “we would not build that yet”. A pitch with no friction in it is a pitch where nobody is protecting your money, and on a build that can run well into five figures, that absence is not politeness. It is a risk. Knowing how to scope an app project before you commit makes these conversations sharper, because you arrive already knowing what is core and what is optional.
Red flag five: vague answers about who owns what
The last one only bites at the end, which is why it is so easy to ignore at the start. Ask who owns the source code, the app store accounts, the design files, and the intellectual property when the project is done. The answer should be simple and it should be you. If a developer gets cloudy here, talks about licensing what you have paid to build, or wants the app published under their own developer account, slow down.
I have seen founders discover, months later, that they cannot move their own app to a new team because the code lives in a repository they have no access to, or the App Store listing belongs to an agency that has stopped replying. Ownership is cheap to settle in a contract and brutally expensive to untangle afterwards. A reputable developer will put it in writing without being chased. One who hesitates is telling you something about how the relationship ends, before it has even begun.
What to do next
None of these red flags means a developer is dishonest. Plenty are simply careless, or optimistic, or used to clients who never ask. But your job as the founder is not to assume the best. It is to ask the question that makes the answer clear, and then to watch how comfortably it comes. A fixed price too early, no curiosity about users, a vanishing senior team, total agreement, and fuzzy ownership. Five things, five questions, and most weak pitches fail at least one of them in the room.
If you are weighing up a proposal right now and something in it is nagging at you, that instinct is usually worth trusting. Send us what you have and tell us what is giving you pause. We will tell you honestly whether it is a real red flag or just an unfamiliar way of working, even if the answer is that the other team is the right one for you.
.webp)
.webp)
