Two quotes arrive for the same dealer portal: ₹6.2 lakh and ₹8.1 lakh. Six months later the cheaper one has cost ₹9 lakh, the portal still cannot handle GST credit notes, and the vendor is billing ₹2,200 an hour to fix it. Pricing custom software is not a comparison of totals. It is a comparison of what each vendor quietly left out.
Why do fixed-price quotes for custom software go wrong?
Fixed-price quotes go wrong because the buyer asks for a number before the scope exists, so the vendor prices the risk rather than the work. The careful ones pad the estimate. The aggressive ones underquote, win the project, and recover margin through change requests once you are committed. Neither outcome tells you what the software will actually cost.
There is a structural reason this happens so often in India: most SMB buyers shortlist three vendors, compare the bottom line, and skip the annexure where the exclusions live. The vendor knows this. Read the exclusions page before the price page, and if there isn't one, ask why.
What should a vendor's estimate itemise?
A usable estimate breaks the number into hours by role, by module and by phase, and states plainly what is out of scope. If you cannot trace the total back to hours, you are looking at a guess dressed as a quote.
Ask to see these lines separately:
- Discovery — one to three weeks of requirements, wireframes and a written scope, typically ₹50,000-₹1.5 lakh for an internal tool or B2B portal
- Build hours by role — senior developer, mid-level developer, QA, with a blended rate you can sanity-check against the ₹1,200-₹2,200 an hour that contract development in India usually runs
- Integrations named individually — Tally or Zoho Books sync, GST e-invoice IRN generation, WhatsApp Business API, payment gateway, SSO
- Third-party costs at actual — cloud hosting, WhatsApp conversation charges, licences
- Handover — deployment, documentation, source code, and a warranty window
- Tax treatment — whether the figure is pre-GST (add 18%) and how TDS under 194J or 194C will be deducted
How a studio publishes its own pricing structure tells you whether it has thought about any of this.
What questions expose a weak estimate fastest?
Five direct questions separate a real estimate from a placeholder, and a competent vendor answers them in one call. Ask how many hours are in the quote and how they were arrived at. Ask the hourly rate for changes and who decides whether something counts as a change. Ask which of your requirements are explicitly excluded. Ask what happens to the price if delivery slips on their side. Ask to see comparable case studies where the final invoice differed from the quote, and why.
Add three commercial ones: who owns the code and IP on final payment, what support costs from month thirteen, and what annual maintenance comes to as a percentage of build cost. In our experience AMC settles around 15-20% of build cost per year. A vendor who dodges the invoice-variance question has told you something useful anyway.
Worked example: two quotes for the same portal
A lower quote is only cheaper if the scope is identical, and on custom software it almost never is. Here is how the arithmetic usually runs.
A B2B distributor wants a dealer portal: GSTIN-verified onboarding, order tracking, credit-note handling, Tally sync and WhatsApp order confirmations. Vendor A quotes ₹6.2 lakh over 10 weeks, with a one-line exclusions note. Vendor B quotes ₹8.1 lakh over 12 weeks and shows the working: ₹55,000 discovery, 480 build hours at a ₹1,450 blended rate, ₹70,000 for infrastructure and deployment, GST extra on both.
Vendor A charges ₹2,200 an hour for changes; Vendor B charges ₹1,500 with eight free hours a month. Four scope rounds totalling about 90 hours push Vendor A to ₹8.2 lakh before the 18% GST, and five weeks late. Vendor B absorbs most of that. Scope creep of 15-30% is normal on portals this size. The only question is whether it was priced in.
How should payments and change requests be structured?
Tie payments to deliverables you can verify, not to calendar dates the vendor sets. A workable split is 20-30% to start, tranches at completed modules, a payment at UAT sign-off, and 10-15% retention released 30-60 days after go-live.
Put the change process in writing before work begins: every change estimated in hours, approved by a named person on your side, and logged. Hold back a contingency of roughly 10% of build cost — not because the vendor will cheat you, but because your own requirements will move once you see the screens. And insist the source code repository sits in an account your company controls from day one. That one clause changes the power equation if the project goes sideways.
Where to start
Write a one-page scope yourself before you speak to anyone: the three workflows that must work, the systems they must connect to, and the deadline that is genuinely fixed. Then ask every vendor to price that page and show their hours, and compare hours rather than totals. If you already have a quote in hand and want a second read on it, Maysan Labs does exactly that as a short paid review — and writes its own estimates the same way it asks other vendors to.
Buying software or a website?
Twelve questions to ask any vendor before you sign: price, your data, fit for an Indian business and support.
Get the free checklistRelated case study
Full-Stack Ecommerce Platform
Needed a complete ecommerce platform built from scratch with inventory, orders, payments, and customer management.
Written by Sanjay Mandal at Maysan Labs, a software studio in Gurgaon, India. Follow us on LinkedIn