Software Development Proposal Red Flags to Catch

Replace with /services/custom-software-development.

Software development proposal red flags, ranked by how hard they are to reverse

Software development proposal red flags differ sharply in cost. Flags that fix scope, ownership and acceptance can sink a project, while a weak cover letter costs nothing. The seven below are ordered by how hard each one is to reverse once work starts:

1. An IP clause that keeps the repo
2. Hours without a scope boundary
3. Milestones with no acceptance criteria
4. No named team
5. "Discovery included" with no deliverable
6. A timeline that ignores your review cycles
7. "AI-powered" with no architecture

Read the quote for what it leaves out. A proposal is a sales document, so the strengths are loud and the gaps are silent. The gaps are where change requests come from.

Use the list below to triage before you read line items. Hold up signature on anything marked Critical until it is fixed in writing. Trade the rest against price and timeline when you evaluate a development proposal side by side with others.

• 1. IP clause keeps the repo (Critical). Fix: assignment on payment.
• 2. Hours with no scope boundary (Critical). Fix: written exclusions.
• 3. Milestones with no acceptance criteria (High). Fix: testable criteria per milestone.
• 4. No named team (High). Fix: named roles and substitution rules.
• 5. "Discovery included" with no deliverable (Medium). Fix: defined outputs and a decision gate.
• 6. Timeline that ignores your review cycles (Medium). Fix: client review time as a line item.
• 7. "AI-powered" with no architecture (Medium). Fix: components, data flow and an evaluation plan.

Who owns the code under an IP clause that keeps the repo?

Check who owns the code on the day you pay. If the proposal is silent, or says the vendor retains "background IP" without defining it, you may be paying for software you are only licensed to use.

Under US law, commissioned software generally does not qualify as a work made for hire unless it falls within specific categories listed in 17 U.S.C. § 101, as explained in the US Copyright Office's Circular 30.

The practical consequence is that without a written assignment, the contractor can keep the copyright. Other jurisdictions differ, so have counsel check the governing law.

Ask for these in the contract:

• Assignment of all deliverables on payment.
• A clear list of any vendor-owned components, with a perpetual licence to you.
• The repository hosted in your organisation from day one.
• Credentials, infrastructure-as-code and documentation handed over at each milestone, not at the end.

Software development proposal red flags: hours without a scope boundary

A quote built on hours alone transfers all estimation risk to you. Without a written scope boundary, every ambiguous feature becomes billable time.

Look for an exclusions section. A competent proposal says what is out:

• third-party integrations not listed
• data migration
• native mobile
• load testing
• content entry
• post-launch support

Look also for assumptions such as "client provides API access by week two", because assumptions are where blame is assigned later.

Time and materials is a legitimate model when the problem is exploratory. The red flag is hours presented as if they were a fixed scope, with a total that looks firm and a rate card that quietly governs everything beyond it.

Put three questions to the vendor:

• Which commercial model applies?
• What happens at 80% of the estimate?
• Who approves overruns before they are incurred?

For how we think about commercial shape, see how we scope custom software work.

What makes a milestone testable?

A milestone that says "Phase 2: backend development" has no way to be failed, so it has no way to be passed. Payment tied to it is payment tied to the calendar.

Acceptance criteria turn a milestone into a test. "Users can reset a password by email, and the link expires after 30 minutes" can be checked. "Authentication module complete" cannot. Each milestone should name:

• the behaviour being delivered
• the environment it is demonstrated in
• who signs off
• how many working days you have to respond

Also check for a defect process. Who fixes bugs found after acceptance, for how long, and at whose cost? GAO's Agile Assessment Guide, written for federal programmes, makes the same point about iterative delivery: speed of iteration still has to be measured against defined outcomes.

Who is actually on the team?

If a proposal says "a dedicated team of senior engineers" and names nobody, you are buying a role description, not people. The people who present the deal are often not the people who write the code.

Ask for names, seniority, location and allocation for every role, and ask what happens when someone leaves. Substitution clauses should require your consent for the tech lead and an overlap period for handover.

A vendor that has run delivery for years should be able to name its leads. At Viithiisys, engineering runs out of Mohali in the Chandigarh tricity, with a Canadian office in Markham, Ontario, and a buyer can ask to meet the lead before signing.

Be cautious about padded org charts too. A project manager, a scrum master, a delivery manager and a "solution architect" at fractional allocations usually means overhead priced as headcount.

What does a discovery phase have to deliver?

A discovery phase is only real if it ends in documents you can take elsewhere. "Discovery included" with no named outputs is a free sales call dressed up as a work package.

Ask what exists on the last day. A usable discovery produces:

• a scoped backlog
• an architecture sketch
• a risk list
• a go or no-go recommendation you could hand to a different vendor

If the proposal prices the build before discovery has happened, the number was invented and discovery is theatre.

The failure mode runs both ways. Some vendors bundle discovery to win the deal, then discover that the scope is bigger than quoted and ask for a change order on day ten. A paid, bounded discovery with a decision gate is more honest, and you keep the right to walk away with the outputs.

Does the timeline account for your review cycles?

A delivery plan that assumes instant feedback is a plan that will slip, and the slip will be attributed to you. Your review time is part of the critical path.

Check whether the schedule lists your obligations: design approvals, content, access to systems, security review, procurement. If each milestone needs three days of your attention and your reviewers have a fortnight's backlog, a 12-week plan becomes 18 before anyone has been negligent.

Ask the vendor to mark client dependencies in the timeline and to state what happens to the delivery date when they are late. A fair clause lets the date move by the delay, nothing more.

A short, bounded build can avoid much of this risk. A fixed-scope offer such as our Moonship MVP is built around a short, agreed timeline. It only holds if you agree your decision points and review turnaround up front, because a late approval moves a fixed-scope date just as it moves any other.

Software development proposal red flags in "AI-powered" claims

"AI-powered" is a claim, not a design. If the proposal does not say which model, which data, which retrieval or tool-calling approach and how quality is measured, nobody has designed it yet.

Regulators have noticed the gap between claim and capability. The FTC announced a crackdown on deceptive AI claims in September 2024, and the SEC charged two investment advisers in March 2024 for false statements about their use of AI.

A credible AI proposal names:

• the components
• the data flow
• an evaluation set
• a fallback when the model is wrong
• the running cost per request class

If you are unsure what to demand, an AI consulting review before signing is cheaper than discovering the gap in month three. Note that this is a Viithiisys service, so weigh our view accordingly.

How to renegotiate without losing the vendor

Open with the structure of the deal, not the price. Vendors lose little by clarifying scope and ownership, but they push back when you appear to be fishing for a discount.

What should I send back first?

Send a short list, in priority order: IP assignment, exclusions and assumptions, acceptance criteria per milestone, named team and substitution rules. Tie each to a risk both sides share. A vendor that engages line by line is telling you something good, and one that refuses all four is telling you more.

Can I reduce commitment instead of cost?

Yes. Replace a blind full commitment with a paid discovery phase and a decision gate, or split the build into stages with separate acceptance.

If you lack the internal judgement to run this, a fractional CTO can sit on your side of the table.

Viithiisys has sat on both ends of these negotiations, as the vendor and as the adviser reading someone else's quote.

If you want a second opinion on a quote in hand, book a broken-workflow assessment and we will read it with you, or send us the document directly.