You asked two suppliers for a quote on the same system, and the two numbers that came back are far apart. The cheaper one is tempting, but you have a nagging feeling that you are not comparing like with like, and you are probably right. Quotes for custom software are written in each supplier's own words, with different headings, different assumptions and different things left unsaid. This guide shows you how to translate both into the same terms, so that when you finally compare the price you are comparing the same job.
Why two quotes rarely line up
Custom software has no catalogue and no standard price list, so each supplier decides how to describe the work. One quote may be three paragraphs and a total. The other may be a 12-page proposal with a feature list, a timeline and payment stages. Neither is wrong, but they cannot be set side by side until the missing information has been collected.
The differences usually come from four places:
- Different understanding of the job. Each supplier heard your requirements slightly differently and quoted for what they understood.
- Different things counted as included. Testing, hosting, training and handover may be inside one price and absent from the other.
- Different ways of charging. One may quote a fixed price for a defined scope; another may charge by the hour or day as the work proceeds.
- Different terms around the edges. Ownership, payment stages and what happens after launch are often where two quotes differ most, and where the price is least visible.
If you are still deciding who should build the system, read our guide to choosing between a freelancer, an in-house developer and a development company first. This guide starts once you have two finished quotes in front of you.
Step one: put both quotes on a single sheet
Do not try to compare two documents by flipping between them. Open a spreadsheet or a blank page and make one row for each thing you need to know, with a column for each quote. The row headings are the same for both suppliers; the cells are filled in from what each quote says, or marked "not stated" when it says nothing.
"Not stated" is the most useful entry on the sheet. It marks every place where the price might be hiding a gap, and it becomes your list of questions. The full set of rows is in the comparison sheet later in this guide, and you can copy it as it is.
Compare the scope before you compare anything else
The scope is the written description of what will be built. It is the base that every other line depends on, so compare it first. A price means nothing until you know what it buys.
- Features and screens. Is there a list of what the system will do, or only a general description such as "an inventory system"? A list can be checked later; a general description can be argued over.
- Users and roles. How many people will use it, and do different people see and do different things? A quote that assumes a few users may not hold if you have a larger team.
- Platforms. A web app, a mobile app, or both? A quote for one is not comparable with a quote for the other. See web app vs mobile app for how the choice changes the work.
- Connections to other tools. Does the system need to link to accounting software, a payment service or an existing website? Each connection is a separate piece of work.
- Reports and exports. Whether you can pull out the numbers you need is often decided by a line that was never written down.
If one quote has a detailed feature list and the other does not, do not assume the shorter quote covers less or more. Send the detailed list to the second supplier and ask them to confirm, line by line, what they have priced.
Check what is included and what is left out
This is the step that explains most price gaps. Many of the tasks around building software are easy to forget, and a quote is only complete if it says who does each one. Check every quote against the table below.
| Item | The question to ask | If it is not stated |
|---|---|---|
| Design | Are the screens designed for you to approve, or built straight from a description? | You may find out what it looks like only when it is done |
| Testing | Who tests the system before you see it, and what do you test yourself? | You may be the tester without knowing it |
| Hosting and domain | Is a place to run the system included, and who pays for it afterwards? | A running cost can appear after launch |
| Data migration | Is moving your existing records into the new system included? See moving your data into a new system. | You may have to prepare and load the data yourself |
| Training | Is anyone shown how to use it, and in what form? | Your team may be left to work it out |
| Documentation and handover | What do you receive at the end, and in what form? | Another developer may struggle to take over |
| Third-party fees | Does the system rely on paid services, such as a payment gateway or messaging, and who pays? | Recurring fees can sit outside the quote |
| Tax | Is the total shown before or after any applicable tax? | The real total may be higher than it appears |
For each "not stated", write the question on your sheet. When the answer comes back in writing, add the cost if there is one. A missing item is normally unpriced work rather than free work.
Why the cheaper quote is not always the smaller scope
It is natural to assume that a lower price means the same job done more cheaply, or a smaller job. In practice there are several other explanations, and only some of them are good news.
- Assumptions that favour the supplier. The price may assume fewer users, simpler rules or less data than you actually have.
- Work pushed onto you. Testing, data preparation, content or project management may be your job under one quote and theirs under the other.
- Changes priced one by one. A low fixed price with every change billed separately can end up higher than a bigger quote that absorbs normal adjustments.
- A different level of experience. A supplier who has built something similar may quote differently from one who is working it out as they go. Ask to see finished work that resembles yours.
- Genuine efficiency. Sometimes a supplier simply has a leaner way of working. You can only tell once the other differences are ruled out.
The same applies in reverse. A higher quote may cover more, or it may be padded. The way to find out is to ask both suppliers to price the same written list. Once the scope and inclusions match, a remaining price difference is a real one.
Read the payment milestones and the dates
The price tells you how much; the milestones tell you when, and what you get for each payment. Two quotes with the same total can carry very different risk.
- What triggers each payment. Look for payments linked to something you can see, such as an agreed scope, a working first version or an accepted finished system, not only to dates.
- How much is due before anything is delivered. A large payment at the start means you carry most of the risk until the first result appears.
- When the final payment is due. It should follow your chance to test the system against what was agreed, not precede it.
- What happens if a milestone slips. Ask what the delivery dates depend on, including anything the supplier needs from you, such as decisions, content or data. How long a custom business system takes explains what drives the timeline.
A short, clear payment schedule is a good sign. A quote that gives a total and no stages leaves you to negotiate the structure later, when you have less leverage.
Compare ownership, access and handover
Two quotes at the same price can leave you in very different positions after the final payment. The questions here are contract matters, so get the answers in writing rather than relying on goodwill.
- Who owns the finished system and its code? Do not assume that paying for the work transfers ownership. Read who owns the source code of your custom business system before you sign.
- Whose name are the accounts in? Hosting, domain and any third-party service the system uses should be registered to your business, or have a clear route to be.
- What do you receive at handover? The code, the documentation, the logins and the data, in a form another developer could pick up.
- Can you leave? If the relationship ends, find out how you would move the system elsewhere and whether anything stops you.
Look at what happens after launch
Every real system needs attention once people start using it. Fixing something that does not work as agreed is different from adding something new, and many disagreements come from a quote that never drew the line.
- Fixes versus changes. Does the quote say how a fault is treated compared with a new request, and who decides which is which?
- How changes are priced. A day rate, a per-change estimate or a monthly arrangement each suits a different pattern of use. Ask for the rate or method in writing.
- How requests are raised. A named contact and a clear way to report a problem matter more than a promise to "support" you.
- What is not covered. Hosting, security updates and third-party services may sit outside the build price. Ask who looks after them.
If a quote says nothing about the period after launch, treat it as "not stated" and ask. It is the part you will need most after the part you are paying for is finished.
A one-page comparison sheet you can copy
Copy this table into a spreadsheet, add a column for each supplier and fill it in from the quotes. Anything blank becomes a question.
| Row | What to record | What a clear answer looks like |
|---|---|---|
| Scope | Features, users, platforms, connections, reports | A written list you could check later |
| Exclusions | What is stated as not included | An explicit list, not silence |
| Included extras | Design, testing, hosting, migration, training, documentation | Each marked included, excluded or optional with a price |
| Price and method | Fixed price or time-based, and what the figure covers | One total, with the method stated |
| Payment stages | What triggers each payment and its share of the total | Stages linked to results you can verify |
| Dates | Start, milestones, launch, and what the supplier needs from you | Dates with stated dependencies |
| Ownership | Who owns the system and code, and whose name the accounts are in | A clear written statement |
| Handover | What you receive at the end | Code, documentation, logins and data listed |
| After launch | How fixes and changes are handled and billed | A named method and a rate or estimate approach |
| Running costs | Hosting, third-party services, tax | Recurring costs listed with who pays |
| Evidence | Similar finished work or a reference | Something you can look at |
Once the sheet is filled in, send each supplier the same short list of follow-up questions in writing. Ask them to confirm the scope as you have written it, to price any item you have added, and to state their position on each "not stated" row. Compare the revised quotes, not the first ones, and keep the replies, because they are part of what you agreed.
Common mistakes
- Comparing totals first. The number is the last thing to compare, not the first.
- Treating silence as inclusion. If a quote does not mention testing or hosting, do not assume it is covered.
- Giving each supplier a different brief. If they quoted for different requirements, the gap in price says nothing about value.
- Accepting a large upfront payment. Tie payments to results you can check.
- Skipping ownership and access. Read the terms before you pay anything, not after.
- Ignoring the cost of change. A system will be adjusted after launch, so price that too.
- Choosing on a conversation alone. A good meeting is not a substitute for a written scope and written answers.
Where Gotka Technologies fits
Gotka Technologies is one development company you can ask for a quote. Its App & System Development service builds web apps, business systems and mobile apps, with indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once the scope is known. These are starting points, so use the comparison sheet in this guide for any quote you receive, including ours. To understand what shapes a mobile build price, see our mobile app cost guide, and if you are still weighing buying against building, read off-the-shelf vs custom software. Whatever is built also needs a reliable place to run, which is where Gotka's Cloud Hosting comes in.
Key terms used in this guide
- Scope: the written description of what will be built and what will not.
- Written quote: a priced proposal that states what is included, so quotes can be compared.
- Fixed price: a single agreed price for a defined scope.
- Time-based pricing: charging by the hour or day as the work proceeds.
- Milestone: a defined stage of the project that triggers a payment.
- Exclusion: something a quote states is not included in its price.
- Handover: the transfer of the finished system, access and documentation to the business.
- Change request: a request to add or alter something that was not in the agreed scope.
- Data migration: moving existing records from an old tool into the new system.
How do I compare two software development quotes?
Put both on one sheet and compare the same rows: what is being built, what is included and excluded, how payment is split, who owns the code, what happens after launch and how changes are priced. Only then compare totals. Where a quote is silent on a row, ask the supplier to answer in writing, because a missing item is usually unpriced work rather than free work.
Why is one custom software quote much cheaper than the other?
A large gap usually comes from a difference in what is covered, not from one supplier being more efficient. The cheaper quote may leave out testing, hosting, data migration, training or handover, assume fewer features or users, or price every change separately. Ask both suppliers to confirm the same list of inclusions, then compare the adjusted totals.
What should a custom software quote include?
A usable quote describes what will be built and for whom, lists what is excluded, states the price and what it covers, sets out payment milestones, names who owns the finished system and its code, and explains how fixes and changes after launch are handled and billed. If any of these is missing, ask for it in writing before you compare the price.
How should payments be split on a custom software project?
Payments are usually tied to stages you can verify, such as an agreed scope, a working first version and acceptance of the finished system. Check that each payment is linked to something you can see, and that the final payment is due only after you have tested the system against what was agreed. Avoid paying most of the price before anything is delivered.
Should I always choose the cheapest quote?
No. The lowest total is only good value if it covers the same scope as the others. A cheaper quote that leaves out testing, hosting or handover can cost more once you add those yourself or pay for each change. Choose the quote that is clearest about scope, ownership and after-launch terms, and then weigh the adjusted price.
How much does Gotka charge to build custom software?
Gotka's App & System Development service has indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps. These are indicative starting points rather than fixed prices, and each project is confirmed by a written quote once the scope is understood.
Off-the-Shelf Software vs a Custom System: How to Choose
Off-the-shelf software works for most growing businesses, but not all of them. A framework for choosing between buying, customising or building custom software.
App DevelopmentWho Owns the Source Code of Your Custom Business System?
Who owns the source code of a custom business system you paid for in Malaysia? What the Copyright Act 1987 defaults to, and what to confirm before signing.
App DevelopmentHow Long Does Building a Custom Business System Take, Realistically?
A single-workflow business tool takes 4 to 6 weeks; a multi-role system with integrations runs 2 to 4 months. What actually drives a custom system's timeline.