How to read a software proposal: scope, source code and NDAs
When you read a software proposal, look at the scope before the price: what will be built, what will not, and when the work counts as “done” should all be written down plainly. Then check who will own the source code, the non-disclosure agreement (NDA), maintenance, and how out-of-scope requests will be handled. The right way to compare two proposals is not by their totals, but by how clearly they answer these points.
We do not work from a price list. For every project we send a written proposal after a first conversation. Here we go through the points we pay attention to when we write our own.
Why do proposals for the same job differ so much?
Send the same brief to three software teams and wide gaps between the figures are normal. The cause is usually not pricing but how each team has understood the job. One team reads “user login” as email and password only. Another includes password reset, two-step verification and an admin panel. The vaguer the proposal, the later those differences surface — usually halfway through the project.
A concrete example. A company asks for three proposals for a panel where its dealers can place orders. The first is a one-line feature list and a total. The second counts the screens but never mentions dealer permissions. The third states that each dealer sees only their own orders, that managers can report on all of them, that the accounting export comes in phase two, and that importing data from existing spreadsheets is out of scope. The third may look the most expensive. In fact it is the only one you can genuinely compare; the true cost of the other two will appear after the project starts.
That is why a good proposal is, before it is a figure, an agreement.
Scope: the heart of the proposal
The scope section should be the longest part of the proposal, and the one you read most carefully.
What will be built?
Features should be described by what a user can do, not by headings. Rather than “reporting module”, something like: “A manager can choose a date range, see sales broken down by customer and product, and download it as a spreadsheet.”
What will not be built?
Good proposals also state what is out of scope. For example: “Support for a second language is not included in this proposal”, or “Migrating data from the legacy system will be assessed separately.” Lines like these prevent the later “we assumed that was included” conversation.
When is it “done”?
Every deliverable needs acceptance criteria: what will be tested when the work is finished, and who signs it off. Without criteria, the work never quite ends.
| Vague wording | Clarified wording |
|---|---|
| ”Mobile-friendly" | "Tested on phone and tablet screens, in the listed browsers" |
| "Admin panel" | "Includes adding, editing and deleting records, with role-based access" |
| "Integrations" | "Order export to the named accounting system" |
| "Fast" | "Agreed performance targets, measured with the named tool” |
Deliverables and phases
Tying a large project to a single delivery date is risky. Check whether the proposal splits the work into phases. We start with the part that lifts the most weight, so every delivery leaves you with something that works. You see progress in concrete form, and if the direction needs to change, you can change it early.
Look for:
- The phases and what will be delivered in each
- How each phase will be shown to you (a test build, a live preview, a demo)
- How payments are tied to those phases
- What is expected of you: content, images, access credentials, approval times
The last point is often skipped. Projects run long not only because of developers but also because decisions are waiting on the client’s side. A good proposal says so.
Source code and intellectual property
This is one of the first things to settle before signing.
Who will own the source code?
Some teams deliver software with a licence to use it only; the code stays with them. Others hand the code over in full at delivery. Both are legitimate models, but they lead to different places. If you do not have the code, working with another team later — or growing the software — can become difficult.
On request, we hand the source code over to the client at delivery. We recommend that this is written explicitly into the proposal.
What does a handover include?
A “source code handover” should be more than a folder of files. Ask:
- Is the code in a version-control repository you can access?
- Are the installation and deployment steps written down?
- In whose name are the server, the domain and any store accounts?
- Are the third-party services and licences used listed?
For mobile apps, store accounts should be opened in your name; for web projects, the domain should be registered to you. Both are part of the same question. We cover the mobile side separately in the App Store review process.
The non-disclosure agreement (NDA)
Asking for an NDA before sharing your idea, business data or customer information with a software team is entirely normal. When reviewing one, check:
- Which information counts as confidential
- How long the confidentiality obligation lasts
- Whether data is returned or destroyed when the project ends
- Whether the team may show the work in its portfolio
That last point matters to both sides. Some projects appear in a portfolio without naming the client; some never appear at all. Agreeing this at the start avoids discomfort later. We sign NDAs on request and raise the subject in the first conversation.
Maintenance, support and change requests
Software does not end on the day it is delivered. Operating systems, browsers and the platforms it relies on keep changing. The proposal should cover:
- A post-delivery bug-fix period. Within what period, and on what terms, will bugs found after delivery be fixed?
- A maintenance model. Is there monthly maintenance, and what does it cover — security updates, compatibility work, small improvements?
- Response time. When you report a problem, how soon will you hear back? We reply within two business days.
It also helps to define the line between a “bug” and a “new request”. A feature in the scope that does not work is a bug. A feature that was never in the scope is a new request.
Change requests
No project ends exactly as it began. New needs appear as users arrive — that is natural. What matters is that the way changes are handled is agreed in advance:
- The request is submitted in writing.
- The team sets out, in writing, its effect on scope, timeline and cost.
- Once you approve, it is added to the plan.
Without such a process, small requests pile up and the project grows quietly. Nobody notices — until the timeline slips.
Questions to ask before you sign
Ask yourself, and the team:
- Is there anything I assume is included that is not in the scope?
- What will I have in hand at the end of each phase?
- Who will hold the source code and every access credential?
- If something goes wrong after the project ends, whom do I contact, and how?
- When a new request comes up, how will it be handled?
If the proposal does not answer these, ask. Getting the answers in writing protects everyone. And if you are not yet sure you need custom work at all, off-the-shelf or custom software is a good place to start.
Frequently asked questions
Is choosing the cheapest proposal sensible?
Only if the scopes are genuinely equal. A lower figure often reflects a narrower scope, vague acceptance criteria or maintenance left out. Put the scopes side by side before comparing totals.
Why does a source code handover matter?
With the code in your hands, you can keep developing the software with any team, move it to another server, or treat it as an asset of your company. Without it, every change depends on the original team.
Should we sign an NDA before the first conversation?
If what you will share is sensitive, yes. Discussing a general idea rarely needs one. But if you will share business data, customer lists or an unannounced product, signing first is a good habit.
Should a proposal guarantee a delivery date?
It should set out phases and an estimated timeline. It should also state plainly that the timeline depends on both sides: approvals, content and access arriving on time are part of the schedule too.
If you are planning to ask for a software proposal, you can read how we work on our custom software and SaaS page or write to us. After a first conversation, we set the scope out in a written proposal.