A software quote is fair when you can tell exactly what the price buys: a written list of what’s included and what isn’t, how changes get priced, payments tied to work you can test, and a written transfer of the code to you. You can’t judge the price until those are on paper, because two quotes that cover different work can’t be compared.
The checker below walks through 21 items, in five groups. Mark what your quote covers. You get a coverage score, the gaps that matter most, and the questions to send the vendor, ready to copy.
Who this is for: founders and business owners holding a quote for an app, a web platform, or internal software, from an agency or a freelancer. Who should skip it: if you’re hiring a developer by the hour with no defined scope, most of these items don’t apply. Read our guide on how to vet an offshore development team instead.
Scope and price
What gets built
Launch and running costs
Ownership and handover
People and timeline
The 21 things a quote should cover
Each item has a weight. Must-have items count 3, should-have items 2, and good-to-have items 1. “Unclear” counts as half. Items that don’t apply, such as App Store submission on a web-only project, drop out of the score.
| 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? |
What the score means
| 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. |
One rule overrides the score. If any must-have item is missing, don’t sign yet, whatever the coverage says. Those six items are the ones that decide who carries the cost when something goes wrong.
Why “fair” starts with complete
A software quote can only be judged fair once it’s complete, because price comparisons need the same scope on both sides. Most guides on this question tell you to compare three quotes. That only works if the three quotes describe the same project. A $12,000 quote that leaves out design, testing, hosting, and the handover can end up costing more than a $20,000 quote that includes them.
The US government’s own contracting rules make the same point. The Federal Acquisition Regulation says a fixed-price contract places “upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss” (FAR 16.202-1). It also says fixed price suits work bought “on the basis of reasonably definite functional or detailed specifications” (FAR 16.202-2). In plain words: a fixed price is only as fixed as the scope it rests on. Vague scope means the risk comes back to you through change requests.
So check completeness first. Then compare prices between quotes that cover the same items. Our offshore team true-cost calculator helps with the price side once the scopes match.
The gaps that cost the most
Five of the six below are must-have items. Running costs is a should-have, but it is the one buyers tend to find last. When one is missing, you carry the risk it was meant to cover. A gap doesn’t mean the vendor is dishonest. Often it’s just habit, and a good vendor fixes it when asked.
No excluded list
A feature list says what you get. It doesn’t say what you don’t. “User login” might or might not include password reset, Google sign-in, or account deletion. We wrote about this in how we scope fixed-price projects: on most contracts we write, the excluded list is longer than the included one, because that’s where the disputes would have started.
Changes with no price rule
Every project changes. If the quote doesn’t say how a change is priced, the vendor names the price later, when you can’t easily walk away. Look for a sentence like “changes are scoped and priced as their own line before work starts.”
Payments by date or by percentage
“30% on signing, 40% at the midpoint, 30% on completion” pays for time. It doesn’t pay for working software. Ask for each payment to follow something you can test, like a login flow that works or a checkout that takes a test card.
Running costs left out
The build price isn’t the running price. A mobile app needs an Apple Developer Program membership, which Apple lists at “99 USD” a year, and a Google Play developer account, which has “a US$25 one-time registration fee” (both vendor pages, checked 2026-10-13). Add hosting, the domain, email delivery, and any paid APIs. These belong in your budget, in your name. Our App Store and Google Play fee calculator covers the store’s cut of sales.
No written transfer of the code
This is the gap with the biggest cost. Paying for code doesn’t make you its owner in most countries. In the US, a transfer of copyright “is not valid unless an instrument of conveyance” is in writing and signed (17 U.S.C. 204). The UK says the same: “An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor” (CDPA 1988, s.90). Pakistan’s Copyright Ordinance 1962 says “No assignment of the copyright in any work shall be valid unless it is in writing signed by the assignor” (section 15, WIPO Lex text). Our post on who owns the code when you hire an agency has clause wording you can use. It isn’t legal advice.
The repository lives in the vendor’s account
Even with an assignment, getting the code back from someone else’s account takes their cooperation. Ask for the repository to be created in your GitHub or GitLab organisation on day one. If it already lives elsewhere, GitHub’s transfer guide says a transfer keeps the history: “Git information about commits, including contributions, is preserved.”
What to do with the result
- Score 85% or more with no missing must-haves. The quote is complete. Compare it with others on the same items, then check the vendor itself: reviews you can open, a named engineer, and a small paid first milestone.
- Score 60% to 84%. Copy the questions from the checker and send them. Ask for the answers inside the revised quote or contract, where they bind both sides.
- Below 60%, or any must-have missing. Ask for a written scope before you discuss price. If the vendor won’t write one, that’s your answer.
This is how we write our own quotes. See our pricing and how projects run for the full process. The checker also has its own page: software quote checker.
FAQ
What should a software development quote include?
At minimum: a feature list, a list of what’s excluded, how changes are priced, a payment schedule tied to deliverables, testing, hosting and third-party costs, a bug-fix period after launch, and a written transfer of the code and IP to you. The table above lists all 21 items with the question to ask for each.
How do I know if a software quote is too cheap?
Check what it leaves out before you judge the number. Low quotes often skip design, testing, data migration, or support after launch. Once two quotes cover the same items, a big price gap is worth a direct question: what are you doing differently?
Why are software quotes so different for the same project?
Because they usually aren’t for the same project. Each vendor fills the gaps in your brief with its own guesses. A written scope with an excluded list is what makes quotes comparable.
Should I pay a deposit for software development?
A first payment is normal. Keep it small, and tie it to something you get, such as the written scope or approved designs. Avoid paying most of the price before you can test any working software.
Who owns the code if the quote doesn’t say?
Usually the vendor, or the developers who wrote it, until a signed written assignment moves it to you. That’s true under US, UK, and Pakistan law. Get the assignment into the contract before work starts.