Topics: Custom software & SaaS, Costs & pricing
Want this done for your business? Get a fixed quote or book a free 30-minute call.
Quick answer: Give every vendor the same written brief, then rebuild each quote into the same eight lines: discovery, UX/UI design, build, QA, DevOps, project management, launch and warranty. Add the running costs each quote leaves out, check how tax is treated, and only then compare totals, using a weighted score rather than price alone.
Picture three proposals for the same booking platform. One says ₹4 lakh and fits on a page. One says ₹11 lakh with a twenty-page scope. One is from an Australian studio at A$60k with a discovery phase you didn't ask for. They look like three prices for one product. They're usually three different products, described in three different ways.
The method below turns them into something you can actually compare. It works for Indian, Australian, UK or US vendors, and for apps, portals or internal tools.
Why do quotes for the same software vary so much?
Mostly because each vendor has imagined a different project. Hourly rates matter, but the bigger gaps come from:
- Scope assumptions. One vendor reads "admin panel" as three screens; another plans roles, audit logs and reports.
- Team seniority. A senior-led team costs more per hour and often fewer hours in total.
- Testing. Some quotes include proper QA and automated tests; others assume you'll find the bugs.
- Discovery. Vendors who include a discovery phase price the uncertainty; those who don't price it later as change requests.
- Support. Warranty periods, launch support and handover vary from nothing to months.
- Risk buffer. Fixed-price quotes carry contingency; time-and-materials quotes shift that risk to you.
For context, our published ranges for custom software cost in India run from ₹1.5–5 lakh for a simple tool to ₹12–35 lakh for a mid-size platform, and our guide to custom software cost in Australia covers A$10k–30k simple tools up to A$80k–250k platforms. Quotes far outside those bands deserve a closer look.
How do you give every vendor the same brief?
Write it once, send it to everyone and share every answer with all of them. If you brief one vendor on a call and another by email, you'll get quotes for different projects.
Your brief should cover:
- The problem, who has it and what success looks like
- User types and what each needs to do
- Must-haves, separated clearly from nice-to-haves
- Integrations (payment gateway, accounting, CRM, WhatsApp, maps)
- Platforms: web, Android, iOS, admin panel
- Data to migrate, and from where
- Deadlines that are real, and why
- A budget range, if you're comfortable sharing one
Ask each vendor to itemise the estimate by phase, list their assumptions and exclusions, and name the people who will do the work. If you're not sure how to structure it, our guide on how to write a software requirements document has a template. When one vendor asks a good question, send the question and your answer to all of them.
How do you line up scope, assumptions and exclusions?
Rebuild every quote into the same table, even when the vendor didn't present it that way. Where a quote lumps phases together, ask for the split; reluctance to provide one is information too.
| Line | Vendor A | Vendor B | Vendor C | Notes |
|---|---|---|---|---|
| Discovery and specification | Workshops, written spec, clickable prototype? | |||
| UX/UI design | Number of screens, revision rounds | |||
| Build (front end, back end, integrations) | Which integrations are included | |||
| QA and testing | Manual only, or automated tests too | |||
| DevOps and environments | Staging, CI/CD, monitoring, backups | |||
| Project management | Who, how often you'll meet, demos | |||
| Launch and app store submission | Who owns the accounts | |||
| Warranty and handover | Length, what counts as a defect |
Underneath, list every assumption and exclusion side by side. "Client to provide content", "third-party API costs excluded" and "up to two revision rounds" can each move the real cost more than a rate difference.
Where a vendor quotes in hours or person-days rather than money, convert everything to one currency and note the day rate behind it. That exposes a common pattern: a low total built on very few testing or project management days. Compare the share of effort each vendor puts into design and QA, not just the totals. A build line that dwarfs everything else usually means the details will be worked out while coding, at your expense.
Which hidden items change the real total?
Running costs and third-party charges, which most quotes leave out by design. Add a row for each:
- [ ] Hosting and cloud services, including staging environments
- [ ] Third-party licences: maps, email delivery, SMS, analytics, error monitoring
- [ ] Apple and Google developer account fees for mobile apps
- [ ] WhatsApp Business Platform message charges, if the app sends messages
- [ ] Payment gateway fees on every transaction
- [ ] Domain, email and SSL, where not already in place
- [ ] Data migration and clean-up
- [ ] Training and documentation for your team
- [ ] Ongoing maintenance, typically 15–25% of the build cost per year
Then check the tax treatment. Indian vendors charge 18% GST to clients in India. Software services exported to a client abroad, such as an Australian business, are usually zero-rated when the conditions for an export of services are met, so no Indian GST appears on the invoice. Australian vendors registered for GST add 10%. An Australian business buying from an offshore vendor should ask its accountant whether the reverse-charge rules apply to it. UK vendors registered for VAT add it at the standard rate, and in the USA sales tax on software and digital services varies by state. Compare quotes on the same basis, either all before tax or all after.
How do team, process and contract model affect value?
The same scope delivered by a different team on different terms is a different deal. Ask each vendor:
- Who exactly will work on the project, at what seniority, and for what share of their time?
- Who is your day-to-day contact, and do they understand the business problem?
- How often will you see working software? Fortnightly demos beat a single reveal at the end.
- What happens when requirements change mid-project?
The contract model matters as much as the price. Our comparison of fixed price vs time and materials explains how each shifts risk. Whatever the model, tie payment milestones to working demos you can click through, not to calendar dates or "design complete" documents.
How do you score proposals with a weighted matrix?
Agree the weights before you open the quotes, then score each vendor from 1 to 5. Adjust the weights to suit your project; these suit most small-business builds:
| Criterion | Weight | What a 5 looks like |
|---|---|---|
| Understanding of the problem | 25% | Restates your goals better than your brief did, asks sharp questions |
| Scope completeness | 20% | Itemised, assumptions explicit, nothing important missing |
| Team and relevant experience | 15% | Named people, similar projects you can see or test |
| Process and communication | 15% | Regular demos, clear change process, responsive during the quote |
| Total cost of ownership | 15% | Build plus three years of running costs, competitive and clear |
| Contract terms and ownership | 10% | Code and accounts in your name, fair warranty, sensible exit |
Multiply each score by its weight and add them up. For example, a vendor scoring 4, 3, 4, 5, 3 and 4 down the table earns 100 + 60 + 60 + 75 + 45 + 40 = 380 out of a possible 500. If two vendors land close together, a short paid discovery with your favourite is cheaper than a wrong choice. Our list of questions to ask a software development company helps fill in the scores.
Which red flags should end the conversation?
Some answers matter more than any price. Walk away when you see:
- A quote far below the others with no explanation; it almost always means missing scope
- No questions asked before the price arrived
- Refusal to itemise, list assumptions or name the team
- Code, cloud or app store accounts held in the vendor's name with no transfer clause
- Large upfront payments before any working software
- No testing in the plan, or testing described as "included" with no detail
- Guaranteed deadlines on a scope nobody has examined
- No live work you can open and use
Frequently asked questions
Why is one software quote three times higher than another?
Usually because the vendors have scoped different projects. The higher quote often includes discovery, testing, DevOps, project management and warranty that the lower one leaves out, and may use a more senior team. Rebuild both quotes into the same line items before judging.
How many quotes should I get for a software project?
Three is usually enough to see a pattern without drowning in proposals. Fewer gives you nothing to compare; many more takes time you'd spend better answering vendors' questions and checking their past work.
Should I pick the cheapest software quote?
Only if, once normalised, it covers the same scope with a credible team and fair terms. A quote far below the rest usually means missing scope, which comes back later as change requests. Pick the best weighted score, not the lowest number.
What should a software development quote include?
An itemised estimate by phase, written assumptions and exclusions, the team, a timeline with milestones, the contract model and payment terms, warranty and support terms, and who owns the code and accounts. Running costs such as hosting and licences should at least be listed, even if they're estimates.
Do software quotes include GST?
Not always, so ask. Indian vendors add 18% GST for clients in India, Australian vendors registered for GST add 10%, and exports of services from India are usually zero-rated. Compare every quote on the same basis, either all excluding or all including tax.
Want a quote you can compare line by line?
Send us your brief and we'll come back with an itemised proposal, written assumptions and a timeline you can hold us to. You can get a fixed quote, usually within one business day, or book a free call to talk the project through first.