A proposal's job is not to persuade; it is to prove that both sides understand the same thing. Proposals that fail at this win the work and lose the project. The ten items below are the skeleton of every proposal we send.
The same items are useful when you're comparing proposals you've already received. If two proposals both list "customer management, reporting, and an admin panel" and the prices are very different, the gap usually comes from undefined work behind those headings.
A proposal that does not state what is out of scope is not a proposal; it is a postponed dispute.
01The problem, the scope, and what is out of it
A proposal opens with the problem, written in the client's own words. If we paraphrase it in ours, any misunderstanding becomes visible immediately — which is good, because it becomes visible before the contract.
Then scope, as a list of items — each one a deliverable, not an intention. The third item is the one most often skipped: what is out of scope. "No mobile app in this release", "content entry is on the client", "third-party integration licences not included". Writing that list is uncomfortable, which is precisely why it is valuable.
02Question the work behind the same heading
Instead of "we want a CRM," a better starting point is "we're missing who to follow up with, and when, in our sales pipeline." Once the problem is clear, the screens and notifications you actually need become concrete too — you don't end up paying for modules you'll never use.
"It has reporting" isn't enough on its own. Which data, over what date range, visible to which users? Is export required? If you need a connection to your accounting, warehouse, payment, or sales system, the proposal should cover more than the integration's name — the direction of the data flow, the technical access required, and what happens when something fails.
03Timeline, milestones and client responsibilities
We express the timeline in milestones rather than week numbers: design sign-off, internal release, acceptance testing, go-live. Every milestone has an artefact and a named approver. Dates hang off the milestones, not the other way round.
The fifth item is client responsibilities, the source of most delays: brand files, domain access, credentials for the accounting integration, content copy, realistic sample data for testing. Putting these in the proposal with dates is not about assigning blame; it is so both sides can plan.
04Ask about the first working version in phased delivery
Ask what you'll actually be able to do with the first working version. A service business, for example, might start with creating work orders, assigning technicians, and tracking status, leaving in-depth analytics for a later phase. This is a representative example — the right order depends on your own priorities. We wrote about keeping the first version small and complete in MVP software: launch your first version faster.
How change requests will be handled also belongs in the proposal. New ideas naturally come up during development, but quietly folding every new request into the existing date isn't reliable. The proposal should show how a change affects cost, timeline, and the other features.
05Data, permissions, and source-code terms
Staff, managers, and customers shouldn't see the same information. Data transfer, backups, source-code handover, and third-party licenses need to be spelled out clearly. Knowing in advance which files and access will be handed over at the end of the project matters; we detailed our own version of this in what belongs in a turnkey software delivery package.
06Price, payment plan, warranty and handover
Price comes with a payment plan tied to milestones, not to the calendar. Currency, VAT treatment and the date on which the exchange rate is fixed are stated explicitly — for EU clients that single line removes half the follow-up correspondence.
The last three items: the warranty period and what it covers, the contents of the handover package, and the proposal's expiry date. The expiry is not a pressure tactic — it is so we can answer honestly when someone asks three months later whether it still stands.
Bug fixes, new feature development, and maintenance are different kinds of work. Ask for the scope and the communication method, rather than a broad line like "support included." Within our turnkey scope, we install the agreed software on a server that meets its technical requirements, test it, and deliver it working. We provide a 12-month bug-fix warranty from delivery; new features are scoped separately. Standard support runs during working hours; a separate 24-hour support package and a separate annual maintenance agreement can be arranged on request. We offer our custom software development service under this same scope definition.
07Look for these seven items when comparing proposals
- The problem to be solved written before the list of modules to be purchased
- The user scenarios in scope defined by data, date range, and permissions
- Integrations explained with their direction, access, and failure behavior
- What the first working version will complete, and its acceptance criteria written down
- Data transfer, permissions, source-code handover, and licenses stated clearly
- How a change request's effect on cost and timeline will be shown
- Warranty, support, and maintenance each defined separately
Written by
The Paradigma7 team
Product, engineering and operations
We are an Ankara-based team building software for Europe. Nothing here is theory: these are the processes we actually run on client projects.
About us