Skip to main content
Dawloom

Software quote checker

Mark what your quote covers. You get a coverage score, the gaps that matter most, and the exact questions to send the vendor before you sign.

Scope and price

  1. A written list of what is included, feature by feature

    Must have. A price with no feature list can mean anything. It is the base every other line rests on.

  2. A written list of what is not included

    Must have. Most disputes start with "I assumed that was in". The excluded list is where those assumptions get caught.

  3. What "done" means for each piece of work

    Should have. Without a test for done, you cannot refuse a payment for work that does not work.

  4. How changes are priced

    Must have. Every project changes. If the quote is silent, the vendor sets the price of each change after you depend on them.

  5. Payments tied to deliverables you can test

    Must have. Paying by date or by percentage "complete" pays for time spent, not for working software.

What gets built

  1. UI and UX design, with the number of screens

    Should have. Some quotes cover code only. Design added later is a second bill.

  2. Each third-party integration named (payments, email, maps, accounting)

    Should have. "Integrations" with no names hides the riskiest work in the project.

  3. Testing and QA, and on which devices and browsers

    Should have. If testing is not in the price, you become the tester.

  4. Moving your existing data

    Should have. Importing old records is often the slowest part of a build, and often left out.

Launch and running costs

  1. Hosting: where it runs and the monthly cost

    Should have. The build price is not the running price. You should know the monthly bill before you sign.

  2. Third-party fees and who pays them (store accounts, paid APIs, SMS, email)

    Should have. These are small but they recur, and they belong in your budget, not in a surprise invoice.

  3. App Store and Google Play submission

    Should have. Store review can reject a build. Someone has to fix it and resubmit.

  4. A bug-fix period after launch, with a length in days

    Should have. Bugs show up after real users arrive. A named period makes fixing them part of the deal.

  5. What support costs after that period

    Good to have. Operating systems, browsers, and libraries keep changing. Something will need updating.

Ownership and handover

  1. A written assignment of the code and IP to you

    Must have. In the US, UK, and Pakistan, paying for code does not make you its owner. A signed written transfer does.

  2. The code lives in a repository you own, from day one

    Must have. If the only copy is in the vendor’s account, you depend on them to get it back.

  3. Hosting, domain, and store accounts in your name

    Should have. The person who holds the accounts can switch the product off.

  4. Documentation and a handover, so another team can take over

    Should have. Code nobody else can run keeps you tied to one vendor.

  5. A list of open-source and third-party licences used

    Good to have. Some licences add duties when you ship. You should know which ones are in your product.

People and timeline

  1. Who does the work, and whether any of it is subcontracted

    Should have. The team that sold the project is not always the team that builds it.

  2. A timeline tied to the milestones

    Should have. A single end date gives you no early warning when the project slips.

What a complete quote covers

These are the 21 items the checker asks about. Must-have items weigh 3, should-have items 2, and good-to-have items 1. "Unclear" counts as half. Items you mark "Not needed", like store submission on a web-only project, drop out of the score. The scope items follow the method in our post on how we scope projects.

The 21 things a software quote should cover. Must have counts 3, should have 2, good to have 1.
Item Weight Why it matters Question to ask
Scope and price
A written list of what is included, feature by feature Must have A price with no feature list can mean anything. It is the base every other line rests on. Can you list every feature and screen the price covers?
A written list of what is not included Must have Most disputes start with "I assumed that was in". The excluded list is where those assumptions get caught. What is not included that a buyer might assume is? Please list it.
What "done" means for each piece of work Should have Without a test for done, you cannot refuse a payment for work that does not work. How will we agree that each milestone is finished? What will I be able to test?
How changes are priced Must have Every project changes. If the quote is silent, the vendor sets the price of each change after you depend on them. If I ask for a change, how is it priced and approved before work starts?
Payments tied to deliverables you can test Must have Paying by date or by percentage "complete" pays for time spent, not for working software. Can each payment follow a deliverable I can test, rather than a date?
What gets built
UI and UX design, with the number of screens Should have Some quotes cover code only. Design added later is a second bill. Is design included? How many screens, and do I approve designs before the build?
Each third-party integration named (payments, email, maps, accounting) Should have "Integrations" with no names hides the riskiest work in the project. Which outside services will the software connect to? Please name each one.
Testing and QA, and on which devices and browsers Should have If testing is not in the price, you become the tester. What testing is included, and on which devices and browsers?
Moving your existing data Should have Importing old records is often the slowest part of a build, and often left out. Is importing my existing data included? From which files or systems?
Launch and running costs
Hosting: where it runs and the monthly cost Should have The build price is not the running price. You should know the monthly bill before you sign. Where will it be hosted, about what will it cost each month, and who pays?
Third-party fees and who pays them (store accounts, paid APIs, SMS, email) Should have These are small but they recur, and they belong in your budget, not in a surprise invoice. Which paid services will the project use, and which accounts will I pay for directly?
App Store and Google Play submission Should have Store review can reject a build. Someone has to fix it and resubmit. Is store submission included, and who handles a rejection?
A bug-fix period after launch, with a length in days Should have Bugs show up after real users arrive. A named period makes fixing them part of the deal. How long after launch do you fix bugs at no charge?
What support costs after that period Good to have Operating systems, browsers, and libraries keep changing. Something will need updating. What does support or maintenance cost after the free period ends?
Ownership and handover
A written assignment of the code and IP to you Must have In the US, UK, and Pakistan, paying for code does not make you its owner. A signed written transfer does. Does the contract assign all code and IP to my company in writing? When does it take effect?
The code lives in a repository you own, from day one Must have If the only copy is in the vendor’s account, you depend on them to get it back. Can the repository be created in my GitHub or GitLab account before work starts?
Hosting, domain, and store accounts in your name Should have The person who holds the accounts can switch the product off. Will hosting, the domain, and the store listings be in my company’s name?
Documentation and a handover, so another team can take over Should have Code nobody else can run keeps you tied to one vendor. What documentation do I get, and can another developer deploy it from that alone?
A list of open-source and third-party licences used Good to have Some licences add duties when you ship. You should know which ones are in your product. Can you list the open-source libraries and their licences at handover?
People and timeline
Who does the work, and whether any of it is subcontracted Should have The team that sold the project is not always the team that builds it. Who will write the code, and will any part be subcontracted?
A timeline tied to the milestones Should have A single end date gives you no early warning when the project slips. When is each milestone due, and how will you tell me if one slips?

Coverage bands

Coverage bands. Any missing must-have item overrides the band: do not sign until it is fixed in writing.
Coverage Band What to do
85% to 100% Complete enough to compare The quote covers what matters. Compare it with others on the same items, then check the vendor, not just the paper.
60% to 84% Close the gaps before you sign Send the questions below and ask for a revised quote. A good vendor answers in writing within a few days.
0% to 59% Not ready to sign Too much is missing to know what the price buys. Ask for a written scope first. Do not compare prices yet.

This is how we write our own quotes: a written scope with an excluded list, changes priced as their own line, and payments that follow work you accept. See our pricing and how projects run.

Questions clients ask

Short answers, no sales language. If yours isn't here, ask an engineer directly.

Ask us anything
How do I know if a software quote is fair?

First check that it is complete: a written scope, a list of what is excluded, how changes are priced, payments tied to deliverables, and a written transfer of the code to you. Only then compare prices, and only between quotes that cover the same items.

Does this tool judge the price?

No. It checks what the quote covers, not what it costs. A cheap quote that leaves out testing, hosting, and handover is not cheap. Price comparisons only mean something once both quotes cover the same work.

What should I do if a must-have item is missing?

Do not sign yet. Copy the questions the tool gives you and ask for the answers in writing, inside the quote or the contract. A vendor who will not write down how changes are priced, or who owns the code, is telling you something.

What does "Unclear" mean?

Use it when the quote mentions an item but does not say how much, how long, or who. "Support included" with no number of days is unclear. It counts as half, and it shows up in the questions to send.

Does the tool store my answers?

No. It runs in your browser and nothing you pick is sent anywhere.

Want a quote that covers all of this?

Tell us what you are building. An engineer replies with a written scope, and the price comes after it.

Start a project Book a meeting
Search the whole site