When two quotes for the same software differ, look first at what each one includes, what it assumes and what it leaves out. This guide shows what drives the price of custom software, what a good quote contains, which signs deserve a question and how to compare quotes on equal terms.
It gives no price ranges and no example prices, because a figure without your scope, your users and your systems would be a guess. The aim is to help you ask for numbers you can compare. The worksheet near the end is blank for you to fill in.
What drives the price
Price follows work. The more there is to design, build, connect, test and run, the higher the price. Discuss these drivers before anyone quotes.
- Scope. The number of screens, features, reports and types of user. A feature that sounds small, such as sending a notification, can hide rules about who gets it, when and how.
- Users and permissions. A single role is simpler than several. Each role needs its own screens, rules and tests.
- Integrations. Each connection to another system, such as accounting, payments, delivery or an ERP, is its own piece of work. The other system's documentation and test access affect the effort.
- Existing data. Moving records from spreadsheets or an old system takes time to map, clean and check.
- Design and languages. A custom interface takes more work than standard components. A screen in both Arabic and English needs layout and testing for both reading directions.
- Security and rules. Access controls, activity logs, backups and any sector requirements add work. Say early which data the software will hold.
- Testing. Test rounds and your own acceptance testing take time and should be visible in the quote.
- Hosting and environments. A test copy, a live system, monitoring and backups are separate items, and some carry monthly fees.
- Your side of the work. Slow decisions, late data and missing answers can add cost, especially on time-based contracts.
If you are still deciding whether to build at all, read custom software or off-the-shelf first. If your process lives in spreadsheets today, spreadsheets to one system helps you list what the software must replace.
What a good quote contains
A usable quote reads like a short summary of the contract. Look for these parts, and ask for any that are missing.
- Scope. Written as features and outcomes, with a list of screens or functions, not one sentence.
- Assumptions. The things the price depends on, for example that you supply content by an agreed date, that another system offers test access, or that you give feedback within a set time. If an assumption proves wrong, the price may change.
- Exclusions. What is not included, such as data migration, training, content, translations, third-party licences or hosting.
- Deliverables. What you receive: working software, source code, documentation, and access to accounts and servers. Our guide to who owns the code covers ownership.
- Milestones and payments. Payments tied to deliverables you can check, not only to dates.
- Acceptance. How you will test, who signs off, how many days you have, and what counts as a defect as opposed to a new request.
- Change requests. How a change is raised, estimated, approved and priced, and the rate for extra work. No change work should start without your written yes.
- Fixes after launch. Whether a period of defect fixing is included, how long it lasts and what it covers.
- Support and maintenance. What is covered (bug fixes, updates, hosting, small changes), the response times and the monthly cost.
- Third-party costs. Who pays for licences, cloud hosting, SMS, maps, email services and payment fees, and in whose name each account is opened.
- Team and timeline. Who works on the project, how you will see progress, and which dates depend on you.
- Price basis. Fixed, time-based or capped; the currency; whether tax is included; and how long the quote stays valid.
How the pricing model shapes these parts is covered in fixed price or time and materials, so this guide does not repeat it. If you need a build rather than a package, the custom software page describes that service.
How to read the numbers
- Ask what the total is built from. One way to build a quote is days or hours for each role, multiplied by a rate, plus third-party costs. A total with no breakdown cannot be checked.
- Check the unit. Days and hours are not the same. A day rate can also cover different working hours from one supplier to the next, so ask.
- Look for a contingency line. It is a buffer for unknowns. Ask how it is spent and whether unused money comes back to you.
- Ask about discovery. A supplier may propose a paid first phase that defines scope before the build. Ask what it delivers and whether its cost is credited if you continue.
- Treat an estimate as an estimate. Ask what would move the final figure up or down.
Here is the method, with no figures. Labour is the days or hours a supplier lists, multiplied by the rate for them. If the quote adds a contingency, ask for it both as a percentage and as an amount, and add it to labour. Two quotes can end at the same total and still differ: one may say what happens if the work runs over and the other may not. Only a conversation shows which plan is safer for you.
Signs to ask about
None of these proves that a supplier is a poor choice. Each one is a reason to ask a question before you sign.
- One total with no breakdown, or the words "everything included" with no list.
- No section on assumptions or exclusions.
- Vague scope words such as "full platform" or "all features" without a feature list.
- No acceptance steps, or acceptance that counts as given if you do not reply within a very short time.
- Most of the money due before you see any working software.
- A promise of unlimited changes at a low fixed price, or no change process at all. Ask what the limits are.
- Silence on testing, security, backups, hosting or support after launch.
- Unclear ownership, or no commitment to hand over source code and account access.
- A price far below the others with no explanation. Ask what is missing.
- Pressure to sign today, or a discount that expires within days.
- No named people, no example of similar work and no past client you can speak to.
What public buyers' guidance says
Governments buy software too, and some publish how they do it. These pages are written for public buyers in the UK and the US, so they are not rules for your company. They do back up several points above.
- The UK government's Sourcing Playbook says bidders need a clear technical specification with enough information to make an informed decision. It also discusses whole-life cost, warns against a bias towards low-cost bids and tells buyers to plan early for the end of a contract.
- A solicitation guide from 18F, a team in the US General Services Administration, is written for US federal agencies. It suggests that at the end of each short work cycle the code should be complete, tested, accessible, deployed, documented and secure, and it points to a written quality plan for checking. It also asks for key people, at least the lead developer, to be named.
- GOV.UK, in a page from the UK Intellectual Property Office, says the person or organisation that made a work is its first legal owner. A freelancer usually keeps copyright unless a contract says otherwise, and a commissioner owns the work only if both sides agree that in writing. The page refers to UK law, so ask a qualified adviser what applies in your country and to your contract.
Compare quotes side by side
Ask each supplier to price the same written brief. A one-page brief is enough to start; see a one-page brief for a web agency for the layout. Then build one sheet.
- List each feature and deliverable from your brief as a row, and give each quote its own column.
- Mark every cell as included, excluded or unclear.
- Ask in writing about every unclear cell.
- For each exclusion you still need, ask the supplier for a price and add it to that quote.
- Put the assumptions side by side. Note which ones depend most on you.
- Compare the payment schedule, acceptance steps, change process and support terms.
- Compare who does the work and how often you will see progress.
- Compare totals last.
Use this blank worksheet, one copy for each quote.
- Supplier, quote date and how long the quote stays valid:
- Basis (fixed, time-based or capped), currency, and whether tax is included:
- Days or hours quoted, and the rate for each role:
- Build subtotal (days or hours multiplied by rate):
- Items on your list that the quote excludes, with the supplier's price for each:
- Third-party costs (licences, hosting, messaging, maps) and who pays them:
- Contingency, as a percentage and as an amount, and what it covers:
- Support and maintenance cost each month, and what it covers:
- Assumptions that depend on you:
- Total with the exclusions you still need added back:
Compare the last line of each worksheet, not the first total on each quote.
Questions to ask every supplier
- What is not in this price?
- Which assumptions would change the price?
- How do you estimate a change, and who approves it?
- Who owns the code, the accounts and the data once I pay?
- How will I see progress, and how often?
- What does support cost after launch, and what does it cover?
- If I stop the project halfway, what do I receive?
Keep the cost under control after you sign
Ask for small releases you can test, rather than one large delivery at the end. Keep a written log of every change you request, its estimate and your approval. Test each milestone as it arrives and report problems in writing within the acceptance period. Hosting, support and updates continue after launch, so plan that cost too. Our guide to what happens after launch covers that stage.
This is general information, not legal or tax advice. Check the current rules or ask a qualified adviser before you decide.
ESTASOFT offers custom software from offices in Dubai, Erbil and London. If you want a scope you can compare, our custom software page explains the service, and you can send a short brief on the contact page. You may also like our guide to questions to ask before hiring an agency.
Sources
- The Sourcing Playbook (GOV.UK): clear specifications, whole-life cost, low-bid bias and planning for the end of a contract; the page showed an update of 30 September 2026 (checked 3 November 2026)
- An agile software development solicitation guide, Part II (18F): end-of-cycle expectations, quality plan and key personnel; the page showed no date (checked 3 November 2026)
- Ownership of copyright works (GOV.UK): first owner, freelancers, commissioned work and agreement in writing (checked 3 November 2026)