What you'll get
- 4 copy-ready blocks
- 6 min read
How to make a software project proposal that gets decided rather than filed: write it for the people who were not in the meetings. Nine sections, in the order a busy committee reads, with the wording that prevents the two classic deaths: scope disputes later and silence now.
The nine sections
1. Their problem Half a page, their words, their numbers. No
company history, no "we are delighted".
2. The outcome What is true when this works, measurably.
3. Scope: in and out Two lists. The OUT list prevents the disputes.
4. The approach Phases with checkpoints a buyer can cancel at.
5. The team Named people and their hours, not a bench photo.
6. Timeline Dates from kick-off, dependencies owned by name.
7. Price and One number per option, what it includes, and
assumptions every assumption the price rests on.
8. Proof One relevant example with a result, one page max.
9. The decision ask What a yes looks like, who signs, and the date
the proposal and price expire.Section 1 and 2: Open with them, not you
The first page decides whether page two happens. Open with the problem as they described it, quoting discovery: "the day gets planned at 6am and replanned by 9". Then the outcome in their units: replanning in minutes, overtime down, audit passed. A buyer who sees their own words kept accurately extends that trust to your scope and price. A proposal that opens with your founding story announces that it was written once for everyone.
Section 3: The out-of-scope list is the contract's best friend
In scope: [the five to eight things you will deliver, verb first]
Out of scope (available separately):
- [the adjacent thing they will assume is included]
- [the data migration / training / integration everyone forgets]
- [ongoing support beyond [n] weeks of warranty]Every scope dispute you have ever had was an item missing from the OUT list. Write it from your scars, keep the tone of "available separately" rather than refusal, and section 7's assumptions get shorter too.
Section 4 to 6: Make it cancellable, and name the dependencies
Committees approve small risks, so shape the work as phases with a checkpoint after each: a buyer who can stop after phase one is approving weeks, not quarters, which is the entire logic of entering accounts through one small project (see one project per account). In the timeline, every dependency gets an owner by name: "test data provided by [their person] by [date]". Unowned dependencies are where software timelines go to die, and naming them now is cheaper than arguing about them in week six.
Section 7: Price with its assumptions attached
Option A: [scope summary] [price]
Option B: A plus [the extension] [price]
This price assumes:
- Access to [system/people] within [n] days of kick-off
- [Their side's effort], roughly [n] hours a week
- Decisions on open questions within [n] working days
If an assumption fails, we flag it in writing before any cost changes.Two options, not four; a binary beats a menu. The assumptions list is not legal boilerplate, it is the price's logic shown working, and the last line is the sentence that builds the most trust in the whole document.
Section 9: Ask for a decision, not a read
To proceed: a signed [document] by [date], and a kick-off on [date].
This proposal and its pricing stand until [date, 3 to 4 weeks out].
Questions between now and then: [name, number], usually same day.An expiry date is not pressure, it is scheduling honesty: your team's availability moves. Proposals without an ask and a date are newsletters.
Worked example (illustrative, not a real company)
Tessaro Analytics proposes a data pipeline project to Northfield Logistics. Section 1 quotes the operations director's "two people rebuild the dashboard every Monday". Scope OUT lists historic data cleansing and user training as separate items, which kills the exact dispute that soured their last vendor. The work is two phases with a checkpoint; the finance lead, forwarded the PDF cold, reads sections 1, 7 and 9 in four minutes and asks one question about an assumption. Decision inside three weeks, on the phase one scope. All names are invented.
Five mistakes to avoid
- Opening with your company. Nobody forwards your founding story. Their problem, their words, page one.
- A scope section with no OUT list. What you did not say is what you will argue about. The OUT list is where margins go to survive.
- One big phase. All-or-nothing proposals ask committees for their scariest yes. Checkpoints convert one big decision into three small ones.
- Hiding the assumptions. A price with silent assumptions becomes a discount the first time reality differs. Shown, the same assumptions become change-control.
- Ending without a date. No expiry, no decision mechanics, no named signer means the proposal is homework you assigned to nobody. Section 9 is two sentences; write them.
Why this works on named accounts
Common questions
What should a software project proposal include?
Nine things: the client's problem in their words, a measurable outcome, scope with an explicit out-of-scope list, a phased approach with checkpoints, the named team, a dependency-owned timeline, pricing with its assumptions, one piece of relevant proof and a decision ask with an expiry date.
How long should a software proposal be?
Short enough to be forwarded and read by someone who skipped the meetings: as few pages as the decision needs, with page one carrying the problem and outcome. Detail that only one evaluator needs (full architecture, CVs, compliance) goes in appendices so the deciding readers never wade through it.
How do you price a software project proposal?
As one or two options with every assumption stated: access, client effort, decision turnaround. The assumptions are what make a fixed price survivable, because when one fails you flag it in writing instead of absorbing it. A price without assumptions is a guess wearing a suit.
More from the Academy
One Project per Account: The AI Fact Sheet
For sellers who paste the same account background into a new AI chat every time.
You leave with a fact sheet template, a set of standing instructions and a five-minute weekly update routine.
Enterprise Sales One-Pager
For founders and sales leads at small firms chasing large accounts.
You leave with a single fill-in page: five named accounts, an entry problem and first project for each, the committee, a procurement pack check and five weekly counts.
Second-Meeting Plan
For sellers whose first meetings go well and then go quiet.
You leave with a close for the last five minutes of meeting one, three things to change before meeting two, a 25-minute agenda and an honest parking rule.
Want this in your inbox?
Optional. We use your email only to send you this, nothing else.