How to compare software development proposals
Two proposals with the same price can describe very different projects, and two with different prices can be the same thing with different assumptions. Before comparing totals, compare what each one includes, what it leaves out and what happens when something changes.
Scope: what's in and what's out
A good proposal describes what will be built in enough detail for you to verify it at the end:
- The features of the first version, described by what the user can do.
- The assumptions: what's expected to exist already or be provided by you.
- The exclusions: what's explicitly left out.
If a proposal has no exclusions, it doesn't mean everything is included: it means it hasn't been discussed yet.
What “done” means
- How each delivery is accepted: who reviews it and against which criteria.
- Whether there's a staging environment as well as production.
- Which tests are run before delivery.
- Whether delivery includes deploying to production or only the code.
Code and account ownership
Ask in whose name the repository is, which accounts it's deployed to and what documentation is handed over at the end. We cover this in detail in the guide on who should own the source code.
How changes are handled
In almost every project something changes along the way. It's worth knowing upfront:
- How a scope change is quoted and who approves it.
- Whether a change moves the delivery date and how that's communicated.
- What happens to work already done if something is dropped.
Deliveries and visibility
- How often you'll see working software, not just reports.
- Whether you have access to the repository and a test environment during the project.
- Who your contact is and who does the work.
After launch
- Whether there's a period for fixing bugs at no cost, and how long it lasts.
- How maintenance or later improvements are quoted.
- What happens if you decide another team should continue the project.
Comparison checklist
| Question | Why it matters |
|---|---|
| What's explicitly included and excluded? | Avoids finding out mid-project that something “wasn't in”. |
| How is each delivery accepted? | Defines when something is finished. |
| In whose name are the code and accounts? | Decides whether you can switch vendors. |
| How are changes quoted? | Changes are normal; surprises aren't. |
| How often do I see working progress? | Catches problems early. |
| What happens after launch? | Software needs maintenance. |
What our proposals look like
Before proposing, we work out what the software must do, what exists today and what goes into the first version. The proposal arrives in writing with scope, deliverables and cost, with no commitment, and the repository is in your name from the first commit.
Related services
Other guides
Tell us which process doesn't fit the software you have.
Rather write directly?
- Repository in your name
- Deployed to your accounts
- No proprietary platform