What are the red flags in a software development proposal?

Last updated 2026-09-16

TL;DR

The biggest red flags in a software proposal are a price with no breakdown, features without acceptance tests, payments due before working software, code or app store accounts owned by the vendor, and no testing, security, or handover terms. Send the vendor a written question for each gap and judge how clearly it answers before signing.

The clearest red flag in a software development proposal is anything you cannot check: a price with no breakdown, features described in adjectives, or ownership terms left unstated. A proposal is the vendor's first deliverable. If it is vague where your money and your code are concerned, the project that follows usually is too. Each of the 20 warning signs below comes with the question that makes the vendor fill the gap in writing.

1. PricingFlags 1 to 5
2. ScopeFlags 6 to 10
3. Ownership and contractFlags 11 to 15
4. Quality and securityFlags 16 to 18
5. Vendor behaviorFlags 19 and 20

Which pricing red flags should worry you first?

Pricing red flags in a software proposal are the ones that stop you from comparing vendors or predicting your final bill. A single lump sum, a firm number quoted before any discovery work, front-loaded payments, uncapped hourly billing, and missing third-party costs each shift risk from the vendor to you without saying so.

1. One price with no breakdown

A lump sum hides which features cost what, so you cannot cut scope to fit a budget or compare two vendors line by line.

Ask the vendor: Can you break this into phases and features, with estimated hours for each?

2. A firm price before anyone studied the requirements

A fixed quote made after one sales call is a guess with padding, or a low number the vendor expects to recover through change orders.

Ask the vendor: What assumptions is this price based on, and what happens to it when one turns out wrong?

3. Most of the money due before working software exists

Large deposits leave you with little bargaining power once problems appear. Payments should follow working, demonstrable milestones.

Ask the vendor: Can we tie each payment to a milestone I can test myself, such as a working login or checkout?

1. Discovery signed offScreens, data, and acceptance tests agreed in writing
2. Clickable designEvery screen reviewed in a prototype
3. Working core flowLogin and main feature running on your own device
4. Release buildAccepted against the tests, submitted to the stores

4. Hourly billing with no estimate or cap

Time-and-materials billing is reasonable for changing scope, but without an estimate and a cap the budget is whatever the invoices say.

Ask the vendor: What is your estimate range, and will you stop and ask before exceeding it by more than 10%?

5. Third-party and running costs left out

Hosting, email and SMS services such as Twilio, payment processing through Stripe, and the Apple Developer Program fee of $99 a year all land on you after launch.

Ask the vendor: What will this software cost me per month to run in its first year, and who pays each bill?

What scope red flags hide in a software proposal?

Scope red flags are gaps that let the vendor and you picture different products under the same price. Features described with adjectives, no list of exclusions, no discovery phase, no milestones, and promises of unlimited revisions all postpone the disagreement until money has been spent and changing course costs more.

6. Features described with adjectives instead of outcomes

"Intuitive dashboard" and "scalable backend" cannot be accepted or rejected. A feature needs a testable description of what a user can do.

Ask the vendor: For each feature, what is the acceptance test that proves it is done?

7. No list of what is excluded

Every proposal leaves something out. When exclusions are unwritten, each one returns as a change order.

Ask the vendor: Please list everything this price does not include, such as content entry, data migration, store submission, and support.

8. No discovery or design phase

Skipping discovery means the vendor will write code before anyone has agreed on screens, data, and edge cases, which is the most expensive time to find a misunderstanding.

Ask the vendor: What do I receive before development starts, and can I stop the project after that phase?

9. A single delivery date and no milestones

One date months away gives you no signal until it is missed.

Ask the vendor: What working software will I see every two weeks, and on which dates?

10. Unlimited revisions

No vendor can afford unlimited revisions, so the promise is usually quietly enforced as limited, or paid for through a padded price.

Ask the vendor: How many revision rounds are included per deliverable, and what does an extra round cost?

1. Vague: "Intuitive, scalable user dashboard with modern design"
2. Testable: "A logged-in customer sees their last 12 orders, filters by date, and downloads an invoice PDF within 3 seconds"

Which ownership and contract terms should stop you signing?

Ownership and contract red flags decide whether you control your software after the vendor relationship ends. Watch for code ownership that transfers only on final payment, app store or cloud accounts held in the vendor's name, no termination or handover terms, proprietary platforms only the vendor can maintain, and no written data protection agreement.

11. Code ownership only on final payment, or only a license

If ownership waits for the last invoice, a dispute over that invoice holds the whole codebase. A license instead of ownership may limit what you can change or sell.

Ask the vendor: Can the contract assign ownership of each deliverable to my company as it is paid for?

12. Accounts registered to the vendor

App store listings, cloud hosting, domains, and code repositories in the vendor's name are hard to recover and easy to hold hostage.

Ask the vendor: Will every account be created in my company's name from day one, with your team added as users?

13. No termination or handover clause

Without one, leaving mid-project means negotiating for your own files while the work stands still.

Ask the vendor: If either of us ends the contract, what do I receive, how fast, and at what cost?

14. A proprietary platform only this vendor can maintain

An in-house framework or a no-code platform account tied to the vendor locks you in. Replacing the vendor then means rebuilding the software.

Ask the vendor: Could a different developer take over this code without your company's help? What would they need?

15. No data protection agreement for customer data

A vendor handling personal data needs written terms. Article 28 of the GDPR requires a contract with any processor of EU personal data, and a vendor handling protected health information for a HIPAA-covered business needs a business associate agreement.

Ask the vendor: Where will our customers' data be stored, who can access it, and will you sign our data processing agreement?

What quality and security gaps signal trouble later?

Quality and security gaps are where low proposals save money, and the savings return as bugs, breaches, and emergency fixes after launch. A proposal with no testing line item, no named security standard, and no post-launch support or warranty terms has priced the easy half of the project and left you the hard half.

16. No testing line item

When testing is not scoped, it is squeezed into whatever time remains before the deadline, which is usually none.

Ask the vendor: How many hours are set aside for testing, who does it, and on which devices and browsers?

17. No security standard named

"Enterprise-grade security" is marketing. A real answer names a checklist such as the OWASP Top 10 for web applications or OWASP MASVS for mobile apps.

Ask the vendor: Which security standard will you build and test against, and will you share the results?

18. No warranty period or support terms

Bugs found the week after launch should be fixed for free. Operating-system updates from Apple and Google will need paid work every year.

Ask the vendor: How long do you fix defects for free after launch, and what does ongoing support cost per month?

Which vendor behaviors are red flags on their own?

Some red flags sit in how the vendor sells rather than in the document. An unnamed delivery team and pressure to sign before you can review the terms both predict how the vendor will behave once the contract is signed and your deposit has cleared.

19. The team is unnamed

Senior people sell the project and junior developers or undisclosed subcontractors often build it.

Ask the vendor: Who exactly will work on this, what share of their time, and can I speak with the lead developer before signing?

20. Pressure to sign quickly

Expiring discounts and "our team is only free if you sign this week" push you past the review that would catch flags 1 to 19.

Ask the vendor: Can you hold this price for two weeks while I have the proposal reviewed independently?

The cost of missing these flags is well documented. McKinsey and the University of Oxford studied more than 5,400 IT projects and found large projects ran 45% over budget on average and delivered 56% less value than predicted. That study covered projects above $15 million, where buyers usually have their own technical staff. Owners signing a $50,000 proposal rarely have anyone on their side reading it.

What are the 20 red flags at a glance?

The 20 software proposal red flags fall into five groups, and each has one question that turns a vague promise into a written commitment. Send the vendor every question that applies before signing. A vendor who answers clearly and in writing has passed the most useful test a proposal can give you.

Related guides

• How do I know if a software development quote is fair?
• 10 questions to ask before hiring a software agency
• My app project is over budget and behind schedule. What should I do?
• The Second Opinion: an independent review of a software proposal
• GDPR Article 28: requirements for data processor contracts
• OWASP Top 10 web application security risks

Key takeaways

• A proposal you cannot check line by line cannot be judged, whatever its total price.
• Tie every payment to working software you can test yourself, not to calendar dates.
• Code, app store accounts, cloud hosting, and domains should be in your company's name from day one.
• Missing testing, security, and support terms mean the proposal priced only the easy half of the work.
• A vendor unwilling to answer these questions in writing before signing will not answer them after.

Frequently asked questions

What is the biggest red flag in a software development proposal?

Ownership terms that leave the vendor in control: code that transfers only on final payment, or app store and cloud accounts registered in the vendor's name. Pricing mistakes cost money, but ownership mistakes can stop you from updating, moving, or selling your own software when a dispute or a vendor failure happens.

How much upfront payment is reasonable for a software project?

A modest deposit to reserve the team is normal. The warning sign is paying most of the total before you can test working software. Structure the remaining payments around milestones you can check yourself, such as a working login, a completed checkout, or an app build installed on your own phone.

Should a software proposal include a fixed price?

A fixed price is reasonable only after a discovery phase has defined screens, data, and acceptance tests. Before discovery, a range with stated assumptions is more honest. Under either model, protect yourself with written exclusions, a change request process with approved estimates, and payments released against working milestones.

Who should review a software proposal before I sign it?

Someone with software delivery experience and no stake in which vendor wins. An internal developer, an independent technology advisor, or a technical lawyer for the contract terms can each catch different flags. Avoid reviewers who earn referral fees from vendors or would build the project themselves.

Back to Blog