How to read a software proposal: 12 red flags and a copy-ready SOW template
C.E.O. Bee Engineering19 min read
Read a software proposal starting from the scope, not the price: look for what is out of scope, the acceptance criteria, which delivery each payment depends on, and who owns the accounts and the code. Any line whose answer is not in writing may be a cost left outside the proposal. This article gives a ten-section proposal skeleton, 12 red flags, comparison tables, an example in which a one-line proposal becomes a scope document, and a copy-ready 12-heading scope of work (SOW) template. It is not legal advice.
Proposal, scope of work (SOW) and contract: three different things
In a software project three documents often get blended into one PDF. Before you compare anything, pull them apart.
- A proposal is the vendor's offer: at what price and on what terms they would do the work.
- A scope of work (SOW, statement of work) says what the work is, what will be delivered, how it will be accepted and when it will be done. In project management a SOW is described as a narrative description of a project's work requirement; a typical SOW covers purpose, scope, a deliverables schedule, acceptance criteria and a payment schedule (Wikipedia).
- A contract is the legal text that binds the parties' rights and obligations.
A one-page PDF with a price at the bottom is only a proposal. When scope lives only in conversation, problems come easily: everyone hears the same sentence but imagines a different product, and the difference shows up at the first demo. The approach we describe on our custom software development page rests on this: scope, schedule and cost are put in writing before work starts. This article is about how to read a software proposal: what to look at, how to compare proposals, and what the scope document in your hands should look like. At the end you will find a copy-ready template and a software proposal example in which a one-line proposal is turned into a scope document.
What order to read a proposal in
Most of us read a proposal starting with the price. We suggest the opposite: read the price last, because a price means nothing until you know what it is the price of.
- Look for what is out of scope first. A written list of things that will not be done is the most reliable sign of a proposal that thought about scope. Without one, some of what you assume is included can turn into an extra invoice.
- Check the acceptance criteria. For each deliverable, is it written down how "done" will be recognized?
- Match payments to deliverables. Next to every payment, write which deliverable it depends on; mark the lines that match nothing.
- Find the account and ownership clauses. If they are missing, note "missing"; an absence is information too.
- Turn the gaps into questions. The last column of the red-flag table below is a ready question list. Ask for the answers in writing: an answer given on the phone or in chat does not appear in the written text of the proposal and can be hard to prove later, so get every answer you may want to rely on in writing.
- Read the price last and fill in the comparison table.
One small habit helps while you read: copy the numbers and dates from each proposal onto a separate sheet. The same amount described as "estimated" in one place and "fixed" in another, line items that do not add up to the total, or a date written two different ways are also questions to ask in writing; more often than not they point to a document prepared in a hurry rather than to bad faith.
The ten sections a software proposal should contain
The table below lists ten sections a software proposal (or the scope document attached to it) should answer, and what goes wrong when one is missing. Most sections overlap with what a typical SOW contains; "change management" and "account ownership" are added because they matter specifically in software.
| Section | What it asks | Risk if missing |
|---|---|---|
| 1. Purpose and success criteria | What problem does this solve, and what will we measure when it is done? | Everyone imagines a different "finished" |
| 2. In scope | Which features, screens and integrations will be built? | "I expected that too" at delivery |
| 3. Out of scope | What exactly will not be built? | Whatever is not written becomes a negotiation or an extra invoice |
| 4. Deliverables and acceptance | What is delivered, and which checks must pass before we say "done"? | Acceptance drags on, payment waits, the parties end up on opposite sides |
| 5. Schedule and milestones | What will I see, and when? | One end date and no checkpoints in between |
| 6. Price and payment plan | What is the total, what is included and excluded, which payment depends on which delivery? | Payments unrelated to delivery, unclear VAT |
| 7. Change management | If scope changes, who decides, with what written approval, and how are the effects on price and schedule calculated? | Every change turns into a negotiation |
| 8. Roles and decision times | Who decides, how fast are questions answered, how do you talk to whoever writes the code? | Work stalls on pending approvals, responsibility evaporates |
| 9. Infrastructure, account and access ownership | Whose name are hosting, the domain, store and third-party accounts in? | It becomes a bargaining chip when you leave |
| 10. Ownership, handover, support and termination | When do the code and rights pass to whom, who looks after it after launch, what happens if the work stops midway? | You have a working product that is not yours |
The ten sections in the table help when you read a proposal; the twelve headings of the template below help when you write a scope document. The first nine sections appear in the template in the same order; the tenth section of the table is split into three template headings: intellectual property and source code transfer, defect fixing with support and maintenance, and confidentiality with termination and handover assistance.
A note on acceptance criteria. In software, "built" and "done" are different things. The Scrum Guide's "Definition of Done" is a formal description of the state of an increment when it meets the required quality measures (Scrum Guide 2020). In a proposal the equivalent is a written, testable acceptance criterion for every deliverable.
12 red flags
A red flag does not mean the vendor is acting in bad faith; more often it points to an assumption nobody wrote down. Use the table as a list of questions: put the question in each row to the vendor in writing and get the answer in writing.
| # | Wording or situation | Why it is a problem | Question to ask the vendor |
|---|---|---|---|
| 1 | A one-line scope ("website and admin panel") | The same sentence can describe ten different jobs; it is unclear what the price buys | Which screens and features does this sentence include, and which does it not? Can you write the list? |
| 2 | No acceptance criteria | Only the party that delivers decides when it is "done" | Which checks must pass for us to accept this work? |
| 3 | "Unlimited revisions" | What has no limit has no measure: either it is never honored or the work never ends | What does a revision cover (a correction or a new request), how many rounds, in what time? |
| 4 | Silence on ownership and source code | The transfer of economic rights must be in writing, with each right listed separately (Law No. 5846, Article 52, if Turkish law applies) | When and by what document do the source code and the rights pass to me? |
| 5 | Unclear infrastructure and account ownership | If the domain, hosting or store account is opened in the vendor's name, it becomes a bargaining chip when you leave | In whose name will these accounts be opened, and how is the handover done? |
| 6 | All paid upfront, or a first payment tied to no delivery | You carry all the risk of work that has not been delivered | Which delivery or milestone does each payment depend on? |
| 7 | A date, but no milestones | A delay is noticed only when the last day arrives | What will I see working at the dates in between? |
| 8 | No change management | Every new request becomes a negotiation | How do I submit a change, and when do I get its effect on price and schedule in writing? |
| 9 | Maintenance and support undefined | It is unclear who owns the first bug after launch and whether it is billable | After launch, who fixes what, under which terms and for how long? |
| 10 | VAT and tax unclear | The total can change later | Is the price inclusive or exclusive of VAT? |
| 11 | It is not clear which engineer will write the code | The person who sells and the person who builds may be different people | Who will write the code, and will I be able to talk to them directly? |
| 12 | No verifiable reference | What is claimed cannot be checked | Can I see a live example of a similar job, or speak to a past client who can confirm the work? |
One more point on references: because of confidentiality agreements some studios cannot give client names. In that case, asking for a live demo, screenshots or an engineering note that explains the reasoning behind decisions is a reasonable and verifiable alternative.
If a previous team has already stopped halfway, see taking over an unfinished software project for the audit to run before you take over.
Comparing proposals side by side
Comparing three proposals on total price alone compares the prices of three different jobs. First assume the same scope, then look at how each proposal answers the questions below. In each cell write one of three labels: written (you can quote it from the proposal), verbal (it was said but is not written) or missing. The number of "verbal" and "missing" cells says more than the price difference does.
| Question | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Are in-scope and out-of-scope items written down? | |||
| Is there an acceptance criterion for each delivery? | |||
| Are milestones and interim dates written down? | |||
| Are payments tied to deliveries? | |||
| Is change management defined? | |||
| Whose name are infrastructure and accounts in? | |||
| When and how do the source code and rights transfer? | |||
| Are post-launch support and maintenance defined? | |||
| Is VAT included or excluded? | |||
| Is the engineer who writes the code named, and can you talk to them directly? | |||
| Price |
The price row is at the bottom on purpose. Compare what you are buying first, then what it costs. Check whether the lowest-priced proposal is also the one with the most "missing" cells: the price difference may be a scope difference.
For mobile app proposals there is a line-item model and a blank comparison table in mobile app development cost.
Fixed price, time and materials, hybrid: which when?
A proposal's price comes in one of three forms. Each is right in some situation; the problem is when the model does not match the uncertainty of the work.
| Model | How it works | When it fits | Watch for |
|---|---|---|---|
| Fixed price | One fee for a scope written in advance | The scope is clear and acceptance criteria can be written | If the scope is not settled, either the price balloons or the work is delivered incomplete; change management is essential |
| Time and materials | You pay for the effort spent | The scope is discovered as you go, uncertainty is high | A cap, regular reports and a written point at which you can stop |
| Hybrid | Discovery or a small first phase on time and materials, then a fixed price for the settled scope | You have an idea but the scope is not clear yet | The output of the discovery and the condition for moving to a fixed price must be written |
Uncertainty is greatest at the start of the work, which is why many projects begin with a small phase that settles the scope. Whichever model you use, what happens when scope changes must be written in the proposal.
Scope of work (SOW) template
The outline below is an example of the scope document you can ask to have attached to a software proposal: copy it, fill in the square brackets, and give it to the vendor saying "I want to see an answer to each of these headings in your proposal." The sample clauses are there to give you ideas.
The same template is also available as a printable PDF with room to write each answer, and as an editable Word file with the square brackets highlighted.
- Purpose and success criteria. "This project is carried out to [problem to be solved]. Success is accepted when [measurable criterion] is met (for example: a customer can complete the order form without help)."
- In scope. "The following features are in scope: [feature list, screen list, integration names]. A feature not on the list is out of scope."
- Out of scope. "The following are expressly out of scope: [for example a second platform, multiple languages, migration of old data]. If any of them is requested, item 7 applies."
- Deliverables and acceptance criteria. "Deliverables: [source code, working release, documentation]. Each deliverable has a written acceptance criterion: [criterion]. The client accepts the deliverable in writing within [period] of delivery or rejects it with reasons; the consequence of no response is [consequence agreed by the parties]."
- Schedule and milestones. "The work is divided into [number] milestones: [milestone name and date]. At each milestone the client sees a working release."
- Price and a payment plan tied to milestones. "The total fee is [amount] [including or excluding VAT]. Payments are tied to milestones: [mapping of payments to milestones]. The fee does not change unless the scope changes."
- Change management. "A change of scope is requested by a written change request. The contractor states the effect of the request on price and schedule in writing within [period]; it is not carried out until both parties approve it in writing."
- Roles, communication and decision times. "Decision-maker on the client's side: [name]. Engineer who writes the code on the contractor's side: [name]. Response time to questions: [period]. A decision not made in time may affect the schedule."
- Infrastructure, account and access ownership. "The domain, hosting, storage, store and third-party accounts are opened in the name of [the client or the contractor]. Every account managed by the contractor is transferred to the client by [method]."
- Intellectual property and source code transfer. "[The transferred rights, listed one by one] in the delivered work pass to the client on [condition, for example payment of the fee in full]. The contractor's tools and libraries that existed before the project remain with the contractor; the client receives [a right to use] them."
- Defect fixing, support and maintenance. "For [period] after launch, [type of defect] is fixed free of charge. Support beyond this is set by a separate written annex covering [scope and charges]."
- Confidentiality, termination and handover assistance. "The parties keep shared information confidential. The contract may be terminated on [condition]; on termination the contractor delivers the work, code and documents produced up to that date within [period] and provides [scope] assistance with handover."
If what is being delivered is the move of an AI-built prototype into production, you can borrow the "pass" criteria of the production-readiness audit for the acceptance criteria in item 4.
This template is not a legal text. Have a lawyer draft or read any binding contract.
Software proposal example: turning a one-line scope into a scope document
A fictional example (no figures, no client name): the proposal contains only one line and a single total price under it: "A reservation system will be developed." Turned into a scope document, the same line raises questions that each demand a written answer. For how a similar scenario plays out in a real system, see our Booking & Reservation Platform case.
| SOW heading | The gap the one line leaves | Filled in (example) |
|---|---|---|
| In scope | Customer sign-up? Admin calendar? Confirmation email? | Customer sign-up and login, free-slot selection, a booking confirmation email, an admin calendar |
| Out of scope | Online payment? A mobile app? | Online payment and a mobile app are not in this release |
| Acceptance criterion | What does "works" mean? | If two requests for the same slot arrive at the same time, only one is confirmed and the other user is told the slot is taken |
| Accounts | Whose name are the domain and the email service in? | The domain and the email account are opened in the client's name |
A single sentence turning into a four-row table is exactly the job a scope document does.
Proposal, contract and the lawyer
A proposal and a SOW describe what the work is and how it will be accepted; the legal consequences are set by the contract. The two must not contradict each other; if they do, the contract should say which prevails.
These are the parts to have a lawyer read. Transfer of rights: rules on copyright transfer differ by country. Under Turkish law, Article 52 of Law No. 5846 on Intellectual and Artistic Works requires contracts and dispositions concerning economic rights to be in writing, with the rights concerned listed separately (mevzuat.gov.tr, in Turkish); whether the single sentence "the source code is yours" meets such a requirement is a legal question. Personal data: under Article 12 of Turkey's Law No. 6698 (KVKK), if you are the data controller and personal data is processed on your behalf by someone else, you share responsibility with them for the measures required (mevzuat.gov.tr, in Turkish); if a software company will host your users' data, how this is written in the contract should be settled with a lawyer. Limitation of liability, termination and confidentiality belong in the same group.
This article is not legal advice.
How we do it
Here we only repeat what we say on our site:
- Before work starts, what will be done, in what order and at what price is written down; work does not start until you approve it, and once the scope is approved in writing the price does not change.
- Payments follow the schedule set in the proposal.
- Ownership of the delivered work passes to you when the project fee has been paid in full; our own tools, libraries and frameworks that existed before the project stay with us.
- Unless you choose otherwise we set up and manage hosting, domains, storage and the deployment pipeline; if you have your own accounts we deploy there. If you ever want to move, we help with a clean handover with accounts, domains and documentation.
- You talk directly to the engineer writing your code.
- When development starts, a live project panel opens in your account showing status, quotes and payments.
Details are on our Process and Terms pages. If you have a proposal to compare or a job you want to start, you can look at our custom software development page or tell us about your project.
The template above is not the text of our contract; what binds is the written contract signed for your project.
Frequently asked questions
What is a SOW, and how is it different from a proposal?
A SOW (statement of work, scope document) describes what the work is, what is delivered, how it is accepted and when it is done. A proposal offers a price and terms. A one-page proposal does not replace a SOW; a good proposal either contains one or refers to it.
What happens if I want a change in a fixed-price proposal?
This is a question to ask before signing. In a well-built proposal change management is written down: the effect of a change request on price and schedule is stated in writing and nothing is done until you approve. With us, once the scope is approved in writing the price does not change.
When does the source code become mine?
As we state on our site, ownership of the delivered work passes to you when the project fee has been paid in full; our own tools, libraries and frameworks that existed before the project stay with us. What binds is the signed written contract. If you are getting a quote from another software company, ask the same question in writing.
What should the payment plan look like?
Payments should be tied to a working, acceptable delivery or milestone, and it should be written which payment depends on which delivery. Suitable proportions vary by project, so we do not suggest a percentage. A payment unrelated to delivery is the sixth red flag in the table.
Who prepares the proposal?
Ask the vendor: are the people who prepare the proposal the same people who do the work? The principle we state on our site is that you talk directly to the engineer writing your code, with no account manager relaying requests in between.
Sources
The pages below were opened and read on October 24, 2026.
- Statement of work, Wikipedia · The Scrum Guide 2020
- Law No. 5846 on Intellectual and Artistic Works, mevzuat.gov.tr, in Turkish · Law No. 6698 on the Protection of Personal Data, mevzuat.gov.tr, in Turkish
This article is general information; it is not legal advice.
— Related serviceCustom Software Development