How to Evaluate a Software Proposal: Reading It Line by Line
Published:
When you evaluate a software proposal, look at what the price covers before the price itself: if scope, acceptance criteria, payment milestones, source code ownership and post-launch support aren't in writing, comparing totals tells you very little. Read the proposal as a description of work, setting out what each side will deliver and what counts as done.
Three proposals on your desk may run to two pages, fifteen pages and a single-line email. The figures differ widely, but usually because each supplier is picturing a different project. If you haven't yet decided between custom software vs off-the-shelf, start there; this piece is for businesses already collecting quotes for custom development.
How to evaluate a software proposal: start with scope
Scope is the foundation for everything else. A quote that says "stock module" and one that says "stock records per warehouse, batch tracking, stock-count adjustments and low-stock alerts" may not describe the same thing at all.
A good scope section covers:
- What's included: screens, reports, user roles and integrations (accounting software, e-invoicing provider, courier).
- What's excluded: plain statements such as "A mobile app is not part of this proposal."
- Assumptions: for example, "Existing data will be supplied in spreadsheets in one format", and what happens if that proves wrong.
- Data migration: is it included, and who cleans the data?
A vague proposal rarely means bad faith; more often the supplier hasn't listened closely enough yet. Ask for a discovery session and a revised proposal afterwards.
Acceptance criteria: what does "done" mean?
Most disputes arise at delivery: the supplier says the screen is ready, you say that's not how your business works. Acceptance criteria settle this in advance.
A criterion describes concretely what must work for a feature to count as finished: "When a dealer places an order in the portal, it appears in the ERP as an open order with no manual re-entry and is posted to the dealer's account." That can be tested; "an ordering module will be built" cannot. If there are none, at least ask who tests, how long you have to give feedback and how defects are classified.
Are payments tied to deliverables?
The payment plan shows where the risk sits. In a healthy plan, payments follow work that has been delivered and accepted, not calendar dates.
| Payment structure | What it means |
|---|---|
| Payment at the end of each accepted stage | Risk is shared fairly; progress is visible |
| A reasonable upfront payment plus stages | Common and clear; ask what the upfront payment covers |
| 100% upfront | All the risk is yours; if the project stalls, you have no leverage |
| Fixed monthly fee, no defined deliverables | Can suit long work, but each month's output should be written down |
Stages should be named, such as "Stage 1: stock and customer account modules, ready in staging".
Who owns the source code and the data?
This is often missing, yet it matters most years later. If you part ways with the supplier, you need to be able to hand the system to another team. Ask:
- Will you receive the source code, or only a licence to use it?
- Will you have access to the repository?
- Does the supplier reuse its own components, and on what licence terms?
- Can your data be exported at any time in a readable format?
Unless the contract says so explicitly, ownership of the software may not be what you assume, so read this clause with a lawyer. If personal data is processed, the contract should also set out how data protection responsibilities are shared; check the regulations that apply to you.
Who is responsible for hosting?
Will the system run on your server, in a cloud the supplier manages, or in a cloud account in your name? The proposal should say who pays for servers, who takes backups and how often, who responds to an outage, and whose name the domain and SSL certificate are registered in.
Maintenance, support and response times
Going live is when real use begins, along with small bugs, missing reports and user questions. Check:
- Is there a free bug-fixing period after launch, and how long?
- What does paid maintenance cover afterwards (fixes, updates, security patches)?
- What are the support hours and channels?
- What's the response time for a critical issue? "The system won't open" shouldn't wait as long as a typo in a report.
If this is vague, ask directly whether the team that builds the system will still be involved after launch.
The change request process
New requests appear as ideas become clearer; that's normal. The contract should say how they're handled: the request is made in writing, the supplier states the impact on time and cost in writing, and no work starts without your approval. This protects you from surprise invoices and the supplier from endless scope.
Who's on the team, and who is your contact?
The person who wrote the proposal may not be the one building the system. Ask whether any work will be subcontracted, and find out who does the analysis, who develops and who your single point of contact is.
Costs after launch
The initial price is only part of the total. Factor in server and cloud fees, maintenance and support, third-party licences and services (mapping, SMS, e-invoicing providers), and pricing for extra users or modules. When choosing a software company, compare the total over several years, not just the first.
Red flags
One of these alone may not rule a proposal out, but several together should make you careful:
- A price with no scope. "ERP system: X" on one line doesn't say what you're buying.
- 100% payment upfront. With nothing tied to delivery, your leverage is gone from day one.
- "Everything included". If inclusions aren't listed, the exclusions surface at delivery.
- No demo or interim delivery schedule. If you first see working software at the end, it's too late to change direction.
- Silence on source code and data. An unclear answer is probably not in your favour.
- A proposal written without hearing your needs. A supplier that asks no questions may be offering its own ready-made solution.
Questions to ask in a proposal: checklist
Fill this in for each proposal, and send any unanswered question to the supplier in writing.
| Question to ask | Why it matters |
|---|---|
| What's in scope and out of scope? | You can only compare proposals that describe the same work |
| Are acceptance criteria written for each feature? | Prevents "is it finished?" arguments at delivery |
| Which deliverables are payments tied to? | Shows where the risk sits |
| Who owns the source code and data, and how are they handed over? | You keep the system if you change supplier |
| Who handles servers, backups and the domain? | Roles are clear during an outage or handover |
| What are support hours and critical response times? | The first weeks after launch are the busiest |
| How are change requests priced and approved? | Prevents surprise invoices and endless scope |
| Who works on the project, and who is my single contact? | Stops questions and decisions getting lost |
| Is there a demo and interim delivery schedule? | Shows where the project really stands |
| What are the annual costs after launch? | Shows the total cost beyond the initial price |
Where to start
Before collecting quotes, write on one page which work you run in spreadsheets, on WhatsApp or by hand, which systems the software must talk to, and what must work in the first stage. If stock and orders are still in spreadsheets, our guide to moving from Excel to ERP helps with that preparation.
Give the same page to every supplier so each proposal answers the same question. If you're collecting quotes for custom ERP software or CRM software, feel free to put the same questions to us.
If you'd like to go through a proposal you've received against this list, we're happy to sit down and read it with you.