The biggest red flags in a development proposal are a price quoted without any discovery, scope written as a feature list rather than user journeys, vague or missing exclusions, no mention of testing or security, ownership of code and accounts that stays with the vendor, payment terms not tied to demonstrated work, and a team that is not named. A healthy proposal is specific, lists its assumptions, and reads like it was written for your project.
A proposal is the first piece of work a development company does for you, and it predicts the rest. The problems that derail projects, unclear scope, misaligned expectations, ownership disputes, are usually visible in the proposal if you know what to look for. Here are the twelve signs we tell founders to watch for, and what the healthy version looks like.
Red flags about scope
1. A price with no discovery behind it
If the number arrived after one call and no detailed questions, it is a guess. Either it is padded to cover the unknowns or it will be revised once the work starts. Healthy version: a short discovery phase, or at minimum a detailed questionnaire and a follow-up call, before a fixed price.
2. Scope written as a feature list
"User registration, profiles, search, payments, notifications." Each of those words can mean a day or a month of work. Healthy version: scope written as user journeys with the edge cases named, so both sides know what "payments" includes and what it does not.
3. No exclusions or assumptions section
Every project excludes something. A proposal that does not say what is either hiding it or has not thought about it. Healthy version: an explicit list. Data migration, content, third-party fees, app store submission, hosting setup, post-launch fixes, each marked in or out.
4. Your idea reflected back without any challenge
A proposal that agrees with everything in your brief has not engaged with it. Healthy version: at least one place where they suggest doing something differently, and explain why.
Red flags about process
5. No mention of testing
If testing is not in the proposal, it is not in the budget, and it will be done by you after launch. Healthy version: automated testing, device testing, and a named quality role or phase.
6. No mention of security
Even a simple app stores personal data and often takes payments. Healthy version: a short section on authentication, data protection and payment handling, scaled to the product.
7. Delivery described as a single date
One date at the end means you see nothing until then. Healthy version: milestones every few weeks, each with something you can use or click.
8. Payment terms not tied to demonstrated work
Large payments up front, or payments on calendar dates regardless of progress, put all the risk on you. Healthy version: a deposit to start, then payments on milestones demonstrated as working software.
Red flags about people and ownership
9. No named team
"Our experienced team" is not a team. Healthy version: names and roles for the project manager, lead developer and designer, and the offer to meet them.
10. Ownership that stays with the vendor
Look for licence language instead of assignment, or code that is "made available" rather than owned. Healthy version: intellectual property assigned to you, accounts in your name, in the contract. Our post on who owns the code covers the specifics.
11. Dependence built in
Proprietary frameworks, hosting only they can manage, or a maintenance contract that is mandatory rather than offered. Healthy version: mainstream technologies, documentation, and the stated ability for another team to take over.
Red flags about the document itself
12. A template with your name pasted in
Generic sections, another client's terminology left in, boilerplate about their methodology and nothing about your users. Healthy version: a document that could only have been written for your project.
Comparing proposals
| Check | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Discovery before the price | |||
| Scope as user journeys | |||
| Exclusions listed | |||
| Testing and security described | |||
| Milestones with demos | |||
| Payments tied to milestones | |||
| Team named | |||
| IP assigned, accounts in your name | |||
| Written for your project |
Fill this in for each proposal before you look at the totals. A cheaper proposal with three empty rows is not cheaper. For how to read the numbers themselves, see how to read a development quote.
One flag is a question, several are an answer
Any single item on this list can have an innocent explanation, so ask. A proposal with four or five of them is telling you how the project will go. Believe it.
If you have a proposal and would like a second pair of eyes on it, send it to us. We will tell you what we see, whether or not you end up working with us.
Frequently asked questions
Is a very fast proposal a red flag?
Speed is fine if the proposal is specific. A detailed, project-specific document in two days means an efficient team. A generic document in two hours means a template.
Is a long proposal better than a short one?
Length is not the measure. A four-page proposal with clear scope, exclusions, milestones and ownership terms beats a forty-page one full of methodology. Look for the specific sections, not the page count.
What if the proposal is good but the price is over my budget?
Say so. A good company will show you what can be removed or phased to fit, and what the trade-offs are. That conversation is itself a test of how they will handle scope later.
Should the proposal include the technology choices?
At a high level, yes, with a sentence on why. You want to hear mainstream, well-supported, easy to hire for. You do not need a detailed architecture in a proposal.
Can I ask a company to change its proposal?
Yes, and you should. Ask for exclusions to be listed, milestones to be added, and ownership terms to be clarified. How they respond tells you as much as the original document.