How to Read a Custom Software Proposal Like a Pro

Custom software proposals all look similar from the outside. Logo, executive summary, scope, timeline, price. The differences that matter are buried in the details. Here is how to spot them.

Section 1: The scope description

What you want: specific, named features with clear inclusion criteria. "Login with email + Google OAuth, no SAML in v1" — that's specific. "Authentication system" — that's not.

Red flags:

Bullet points so generic they could describe any project ("user management", "admin dashboard")

No mention of edge cases

No "out of scope" section (the biggest signal)

What good looks like: a 2–4 page scope section listing features, exclusions, integrations, user roles, data model basics, and any constraints.

Section 2: The timeline

What you want: week-by-week breakdown with named deliverables per week, plus a launch date.

Red flags:

"3–6 months" — that's a range, not a commitment

Just a final delivery date with no intermediate milestones

Demo schedule not mentioned

What good looks like: "Week 1 discovery, weeks 2–5 weekly demo cadence, week 6 launch. Specific deliverables per week. Demo every Friday."

Section 3: The price structure

What you want: a fixed total with milestone-based payment schedule.

Red flags:

"Time and materials" without a cap

"Estimated price" with no cap or fixed-quote conversion option

Payment schedule heavily weighted upfront (over 50% before week 4)

Hourly rates without weekly burn-rate cap

What good looks like: fixed quote, 30% kickoff, 40% staging, 30% launch — or similar milestone-tied schedule. Optional maintenance retainer broken out separately.

Section 4: The team

What you want: named individuals who will work on your project, with their roles.

Red flags:

"Senior engineering team" without names

"Project manager" as the only named contact (you'll never talk to engineers)

Mention of subcontractors or offshore teams without specifics

What good looks like: lead engineer's name and GitHub/LinkedIn, designer's name, project lead's name. You should be able to look these people up before signing.

Section 5: The ownership and IP terms

What you want: clear statement that you own the source code, including a license grant and what's deliverable at handover.

Red flags:

"We own the framework / foundation / proprietary platform that this is built on"

"Code is licensed to client for use" (that's not ownership)

"Source code in escrow" with vague trigger conditions

What good looks like: "Client owns the full source code with rights to modify, deploy, sublicense and distribute. All credentials and accounts transferred to client at launch."

Section 6: The exit clauses

What you want: clear exit terms if the relationship doesn't work.

Red flags:

No exit clauses at all

"Termination requires 90 days notice and full balance due"

No mention of what happens to the code if you cancel mid-build

What good looks like: termination at any milestone with paid work delivered, prorated refund if applicable, code delivered as-is at termination.

Section 7: The warranty and maintenance

What you want: a defined warranty period (typically 30–60 days post-launch) covering bugs at no cost, plus optional maintenance retainer.

Red flags:

No warranty mentioned

All bug fixes billable from day 1

Maintenance "included" but without specifying what (and what's not)

What good looks like: 30-day post-launch fix warranty, then optional maintenance retainer with hours-per-month and SLA.

The quick scan

If you only have 5 minutes to evaluate a proposal, look at:

Is there an "out of scope" list? (Most important signal)

Is the price a fixed total or open-ended?

Is the timeline week-by-week or just final?

Are individuals named?

Is source code ownership stated clearly?

If all 5 are clear, you're probably looking at a competent vendor. If 3+ are vague, keep looking.

For our take on how to do this right, see 5 Questions to Ask Any Vendor. Or get a transparent quote yourself via the cost calculator.