Read any software development quote by its sections before its final figure: the written scope, the assumptions, the exclusions, the payment schedule, how changes are priced, the warranty, and who owns the code and accounts after delivery. If any of these is missing, or written in vague phrases such as "a complete system" or "as needed", the number on the page is not what you will actually pay, and the gap will show up later as change requests or disputes over what you agreed.
This guide walks through a quote section by section: one table of what each section should contain and what counts as a red flag, practical steps to compare several quotes, and how we write quotes at HBS. If you are looking for the price ranges themselves and a worked three-year cost example, you will find them in our guide to custom ERP and CRM development cost.
What should a clear software development quote contain?
A good quote describes what you will receive and on what terms. It is not a page with a number and a delivery date. This table shows what each section should contain, and what means you should stop and ask:
| Quote section | What you should find | Red flag |
|---|---|---|
| Scope of work | Modules, screens, user roles, reports and integrations, each named | Phrases such as "a complete system", "and more" or "as needed" |
| Assumptions | What the vendor assumes about you: who prepares data and content, approval times, number of review rounds | No written assumptions, so every later difference becomes "out of scope" |
| Exclusions | An explicit list of what the price does not cover, such as hosting, licences and payment gateway fees | No list at all, or "anything not mentioned" with no detail |
| Timeline | Phases with defined deliverables and a rough duration for each | One final delivery date with no phases |
| Payment schedule | Payments tied to deliverables you can see and test | A large upfront payment, or payments tied to dates instead of delivery |
| Change requests | A written way to estimate and approve any change before work starts | "Unlimited revisions", or no mention at all |
| Testing and acceptance | A testing phase with your team and acceptance criteria for each phase | Delivery counts as acceptance automatically |
| Warranty and support | A period for fixing defects free of charge after launch, and support terms after it | No warranty, or one that does not separate a defect from a new feature |
| Ownership and handover | Code ownership transfer, plus the repository, documentation and access | A "licence to use" only, or server accounts in the vendor's name |
| Tax, currency and validity | Whether the price includes tax, in which currency, and until when the quote is valid | A price with no clear currency or no validity period |
Watch the tax line closely when you compare. As things stand (November 2026), the general VAT rate in Egypt is 14% under Value Added Tax Law No. 67 of 2016, so the gap between a quote that includes tax and one that does not is not small.
How do you read the scope without assuming what is not written?
The scope matters most, because everything else is measured against it. The rule is simple: what is not written in the scope does not exist, even if you discussed it in a meeting. Read it with these questions:
- Are the modules described by their features, or only by name? "Sales module" on its own says nothing. "A sales pipeline with editable stages, quotes in several versions and a performance report per rep" is something you can hold the vendor to.
- Are the roles and permissions defined? The number of user types, and what each one sees, changes the size of the work a lot and is often left out of quotes.
- Are the integrations named? "Integration with other systems" is an open phrase. Ask for names: the accounting software, the payment gateway, the e-invoicing system, WhatsApp.
- Are the platforms and languages clear? Web only, or a mobile app too. Arabic only, or Arabic and English, and who writes and translates the content.
- Are the reports listed by name? "Comprehensive reports" might mean two reports or exactly what your management needs. Only the names tell you which.
Without a written description of what you need, you will receive quotes that are hard to compare, because each company understood something different. Start with a short requirements document sent to everyone in the same form.
Why do assumptions and exclusions matter more than the price?
Assumptions are what the vendor based its price on, and exclusions are what it left out of the price. Together they set the gap between the written number and the real cost. Common assumptions include:
- Your data is ready and clean. If the quote assumes your old data will arrive in a tidy Excel file, who cleans it if it does not, and at what cost?
- Each phase is approved within a set number of days. A delay in your reviews may count as your delay, not the vendor's, and can move the whole delivery date.
- A limited number of design revision rounds. That is normal, as long as the number is written and known to you from the start.
- Third parties provide working APIs. If an integration depends on a system you do not own, what happens if its API is unavailable or undocumented?
If you cannot find the exclusions, ask for them in writing. The most common are hosting and cloud servers, domains, paid licences and plugins, payment gateway and SMS fees, app store fees, and entering old paper records. This list is a good sign: the vendor has thought about the full cost and told you plainly.
How should payments be tied to phases and deliverables?
The payment schedule shows who carries the risk. A large upfront payment moves the risk to you, and payments tied to dates mean you pay even if nothing has been delivered. It is better to tie each payment to a deliverable you can see and test, as in this illustrative example:
| Phase | What you receive before the payment | How you check it |
|---|---|---|
| Kick-off | An approved scope document and phase plan | Check that everything you need is written in it by name |
| Design | Designs of the main screens in Arabic | Walk through the workflow on the prototype before any code |
| Each development phase | A working version on a test environment with the agreed modules | Test it with your team using real data |
| Launch | The system on the servers after data migration | Compare balances and records with the old system |
| End of warranty | Logged defects closed, code and documentation handed over | Confirm full access to the repository and accounts |
Percentages vary by project. What matters is not paying the larger share before you see a working system, and keeping a final payment tied to acceptance. To judge whether the timeline in a quote is realistic, see our article on a realistic custom software development timeline, phase by phase.
How does the quote handle change requests, warranty and support?
Every software project changes during delivery, and that is not a problem in itself. The problem is change without rules. Look for three things in the quote:
- A written process for change requests. You request a change in writing, the vendor replies with a time and cost estimate, and nothing starts before you approve. Ideally the quote states the hourly or daily rate used to price changes.
- A warranty that separates a defect from a new feature. Fixing what does not work as agreed is the vendor's job during the warranty, free of charge. Adding what was not in scope is a change request. Without a stated warranty period and coverage, every fault after launch becomes a negotiation.
- Support after the warranty on known terms. Who answers if the system stops, within how many hours, and what a monthly or yearly maintenance contract costs. You need not sign it now, but know it before you sign.
Who owns the code and the accounts after delivery?
This line is not in the price, but it decides the value of what you pay for. Without the code and the accounts, you are paying for a system that only its builders can move or develop. Make sure the quote states:
- Transfer of source code ownership to you. On payment of what is due, rather than a "licence to use" under which the vendor keeps the code.
- Handover of the repository and technical documentation. Including how to run and deploy the system, so any other team can continue the work.
- Servers, domain and accounts registered in your company's name. Not in the name of the vendor or one of its employees.
- Your right to export all of your data. At any time, in standard formats.
Also make sure these terms carry over to the contract unchanged. The quote sets what you negotiate, and the contract is what protects you.
How do you compare several quotes fairly?
Comparing on the final number alone usually rewards the least clear quote. Follow these steps instead:
- Send everyone the same description. One requirements document in the same form, so you compare quotes for the same project.
- Move every quote into one table. One row for each section of the first table above, one column for each company.
- Mark every empty cell. A line that is not mentioned is not free. Its cost is simply unknown.
- Send your questions in writing and ask for written answers. Then add the answers to the quote or to a signed annex.
- Ask about the team that will deliver. Who will actually work on your project, and do they have similar published projects you can see?
- Calculate the full cost, not the build price alone. Add hosting, licences and two or three years of support to each quote.
- Compare what happens when there is a disagreement. A quote that sets out how changes, acceptance and exit work protects you more than a cheaper one that does not.
If you are still choosing the company itself, see our eight criteria for choosing a software development partner.
How do we write quotes at HBS?
At HBS we do not send a number before we understand how you work. We start with a discovery session to review your processes, your data and the systems the new one must connect to, then we write a scope with clear phases. The quote separates what the price covers from what it does not, so third-party costs such as hosting, domains, paid licences and payment gateway fees sit in their own list instead of surprising you after you sign.
We also know why these lines matter from the client's side. When we built the LDY CMS dashboard for Labib Demian Youssef & Co., one of its modules was a quote builder that adds discounts, 14% VAT as things stand (November 2026), validity, currency, and payment and delivery terms to the line items, and tracks every version of a quote until it is accepted. Training was part of the delivery too: on-site sessions at the company, live webinars, and short Arabic video tutorials for every module. Lines like these are often missing from quotes, then requested later at extra cost.
Legal details and fees in this article reflect the situation in November 2026 and may change; check the official source before you decide.
If you have several software quotes in front of you and are not sure how to compare them, tell us about your project and the systems you work with today. Our team will sit down with you in a free discovery session and help you define the scope to compare against, and you can learn more about HBS custom business software development.
