Direct answer: A weak Pune software quote is not the cheapest or the most expensive one. It is the quote that cannot answer twelve specific questions about scope, ownership, team, money, support and exit. Ask those questions before you compare numbers, score the answers, and walk away from any vendor that cannot give a written, specific response.
Pune's software market is deep enough to give a first-time founder real choice — and wide enough to make that choice risky. The same four-page brief can produce quotes that differ by several lakhs, not because one vendor is honest and another is greedy, but because each vendor has silently decided to build a different product inside the proposal.
If you compare headline numbers first, you will usually pick the wrong partner.
This guide gives you twelve questions to ask every vendor before you sign. Each includes what a weak answer sounds like, what a strong answer sounds like, and what to do when you hear the weak version. At the end you get a scoring rubric and a quote-normalisation worksheet.
Transparency note: JUHENZA is a founder-led studio based in Anand, Gujarat, and works remotely with founders across India, including Pune. It does not claim a Pune office. This guide draws on published procurement guidance and vendor documentation, not on verified client outcomes.
Why Pune founders get wildly different quotes
Pune has large IT services firms, product studios and two-person teams working from the same talent corridor. "Software development company in Pune" therefore covers very different delivery models. A 500-person outsourcing firm and a four-person studio can both send a quote, and both can use the same words — "MVP," "discovery," "support" — while meaning different things.
The price gap is mostly a scope gap. One vendor quotes a CRUD admin panel; another quotes role-based access, payment integration, audit logging and an architecture sized for real concurrency. The screenshots look similar; the systems underneath do not.
Your first job is not to find the cheapest quote. It is to find out which product each vendor actually priced. Our guide to custom software development cost in India explains the cost drivers behind those differences.
That requires questions. Not "What is your process?" — every vendor has a polished answer — but questions that force a specific, written response about what happens when the project becomes difficult.
The 12 questions
Questions 1–3: Scope and product
1. What exactly is in the quote — and what is explicitly out of scope?
Why it matters: A quote without an exclusions list is not a quote; it is an opening bid. The out-of-scope list is where the real boundary of the project lives.
Weak answer: "We'll figure out the details as we go." "The quote covers everything you need for launch." No written exclusions.
Strong answer: A written scope listing users, workflows, integrations, screens and an explicit "not included in this phase" section. The vendor can name at least three things that are out of scope.
If you hear the weak version: Do not compare the number. Ask for a written scope with exclusions before continuing.
2. Which user journeys and acceptance tests define "done" for v1?
Why it matters: "Done" is the difference between a demo and a product. A vendor that cannot describe the acceptance test will define done when the invoice is paid.
Weak answer: "We'll show you a working demo." "You'll know it when you see it."
Strong answer: Named user journeys, acceptance criteria and a test plan. For a booking product, for example: a user can choose a slot, confirm, receive a confirmation and cancel without manual intervention.
If you hear the weak version: Ask the vendor to write one acceptance test for the most important user journey. If they cannot, the scope is not ready.
3. Which existing systems, data sources and third-party dependencies are included — and who owns access?
Why it matters: Integrations are where timelines and budgets quietly expand. A quote that assumes "your team will provide the API" is not the same as one that includes integration work.
Weak answer: "We'll integrate with whatever you have." No mention of API limits, credentials or vendor cooperation.
Strong answer: A named list of systems, the direction of data flow, who provides credentials, and what happens if a third-party API is rate-limited or unavailable.
If you hear the weak version: Add integration ownership to the scope document before signing.
Questions 4–6: Money and ownership
4. Is the price fixed, time-and-materials, or capped T&M — and what triggers a change order?
Why it matters: The pricing model allocates risk. Fixed price suits a well-defined scope; time-and-materials suits an evolving product. Neither is universally better, but ambiguity is always worse.
Weak answer: "It's fixed — unless something changes." No definition of "change."
Strong answer: A clear model, a change-order process and an hourly or daily rate for out-of-scope work. If fixed price, the scope is frozen in writing. If T&M, you receive timesheets or sprint-level effort summaries.
If you hear the weak version: Ask for the change-order clause and a rate card before comparing headline prices.
5. What is the payment schedule tied to — calendar dates or demonstrable milestones?
Why it matters: Paying by calendar date rewards the vendor for waiting. Paying against demonstrable output rewards the vendor for shipping.
Weak answer: "50% upfront, 50% on delivery." "Monthly invoices."
Strong answer: Milestones tied to something you can see and test — for example 30% on signed scope, 30% on a working core journey, 30% on UAT sign-off, 10% on handover. The vendor is comfortable with you withholding final payment until acceptance.
If you hear the weak version: Propose milestone-based payments. A vendor that refuses is telling you something.
6. Who owns the source code, infrastructure accounts and domain — and on what date?
Why it matters: In India, copyright ownership turns on the contract and on the Copyright Act, 1957. "You own it on payment" is not automatic unless the contract says so — Section 17 deals with first ownership, and commissioned work generally needs an assignment clause. Practical control matters too: repository access, cloud accounts and domain credentials.
Weak answer: "We'll transfer everything at the end." "Don't worry, you own it."
Strong answer: A written IP assignment clause, repository access from week one, cloud and domain accounts in your name, and a named transfer date. The vendor can explain the difference between legal title and practical control.
If you hear the weak version: Do not sign until a lawyer reviews the IP clause. This is not legal advice.
Questions 7–9: Team, delivery and support
7. Who specifically writes the code — and can I meet them before signing?
Why it matters: The person who sells the project is not always the person who builds it. Subcontracting is common, and it changes quality, communication and accountability.
Weak answer: "Our team." No names. "We have senior developers." No introduction.
Strong answer: Named engineers or a named technical lead, a short call with the person who will own the architecture, and a clear statement of whether any work is subcontracted.
If you hear the weak version: Ask for a paid discovery session with the delivery lead. If the vendor cannot arrange it, assume the sales team and delivery team are separate.
8. How often will I see working software, and what happens when something breaks?
Why it matters: Weekly demos beat monthly surprises. Incident response is the difference between a vendor and a partner.
Weak answer: "We'll update you regularly." "We'll fix bugs when they come up."
Strong answer: A demo cadence (weekly or fortnightly), a named point of contact, a severity definition, and a response-time expectation for critical issues. The vendor can describe one project where something broke and explain what happened.
If you hear the weak version: Ask for the last three incidents and how they were handled. Vague answers are a red flag.
9. What is the warranty period, and what does post-launch support actually cover?
Why it matters: Launch is the start of the operating problem, not the end of the project. A 30-day warranty and a 90-day warranty are different products.
Weak answer: "We support you after launch." No duration, no scope, no cost.
Strong answer: A stated warranty period, a definition of bug versus enhancement, a support channel, response times, and a separate retainer option with pricing. The vendor can explain what is not covered.
If you hear the weak version: Ask for the support terms in writing before comparing quotes.
Questions 10–12: Risk, proof and exit
10. How do you handle data protection, access control and third-party dependencies?
Why it matters: If your product handles personal data, India's Digital Personal Data Protection Act, 2023 and its rules are relevant. You need to know where data is stored, who can access it, and what happens on a breach.
Weak answer: "We use secure servers." No specifics on encryption, access control or subprocessors.
Strong answer: A description of hosting location, encryption in transit and at rest, role-based access, a subprocessor list, and a data-retention and deletion approach. The vendor can explain how they would support a DPDP-related request.
If you hear the weak version: Add a data-handling annex to the contract and have a lawyer review it. This is not legal advice.
11. What is the exit story — can I take the codebase in-house or to another vendor?
Why it matters: Vendor lock-in is not only about code ownership. It is about undocumented logic, shared toolkits, proprietary components, and knowledge that lives only in the vendor's head.
Weak answer: "Why would you want to leave?" "Everything is documented." No exit process.
Strong answer: A handover checklist, documentation standards, a named exit-support period, and a clear statement of any third-party licences or shared components that would restrict a transition. The vendor can describe what a handover would include.
If you hear the weak version: Ask for a sample handover document from a previous project. If they cannot share one, assume the exit will be painful.
12. What would make you turn down this project?
Why it matters: This question reveals honesty, specialisation and self-awareness. A vendor that says yes to everything is a vendor that will say yes to work it cannot do.
Weak answer: "We take on every project." "We can build anything." No boundaries.
Strong answer: A specific answer — for example, "We would turn this down if you needed a native mobile app and a complex hardware integration in eight weeks, because we do not have the hardware team." The vendor names a real limitation.
If you hear the weak version: Treat enthusiasm without boundaries as a risk signal, not a strength.
How to score the answers
Score each answer from 1 to 3.
| Score | Meaning |
|---|---|
| 1 | Weak: vague, verbal, no written artefact, or refuses to answer |
| 2 | Partial: some specificity, but key details missing or promised later |
| 3 | Strong: specific, written and verifiable; the vendor can show an example |
Total possible: 36.
| Total | Interpretation |
|---|---|
| 30–36 | Strong candidate. Proceed to commercial negotiation and legal review. |
| 22–29 | Conditional. Clarify the weak areas in writing before signing. |
| Below 22 | High risk. Walk away, or restart with a paid discovery to test the vendor. |
Illustrative example (not a verified client case): a first-time founder receives three quotes for a booking MVP at ₹8 lakh, ₹15 lakh and ₹26 lakh. The ₹8 lakh vendor scores 16/36 — no written scope, no acceptance tests, no named engineers. The ₹15 lakh vendor scores 27/36 — good scope, vague on escrow and support. The ₹26 lakh vendor scores 31/36 — strong on team, acceptance tests and exit, but expensive. The founder chooses the ₹15 lakh vendor after clarifying escrow and support in writing, and budgets a 15% contingency. This is a decision framework, not a claim about market outcomes.
Quote normalisation worksheet
Before comparing numbers, rewrite each quote on the same template.
| Dimension | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Users and roles included | |||
| Core user journeys | |||
| Integrations (named systems) | |||
| Acceptance tests | |||
| Out-of-scope list | |||
| Who writes the code (names) | |||
| Repository access from week one? | |||
| IP assignment clause | |||
| Payment milestones | |||
| Warranty period | |||
| Post-launch support cost | |||
| Data-handling / DPDP notes | |||
| Exit / handover plan |
If a vendor cannot fill a row, that row is a risk, not a blank.
Common mistakes
- Comparing headline prices before normalising scope. The cheapest quote is often the one that silently removed the most work.
- Skipping discovery to save time. A vendor that quotes after a two-line idea is guessing. Discovery is where the real scope is found.
- Not meeting the delivery team. A great sales call is not evidence of great engineering.
- Treating "you own the code" as enough. Legal title without repository access, documentation and an exit plan is paper ownership, not practical control.
- Ignoring the exit question because it feels awkward. The best time to plan an exit is before you sign.
- Assuming a Pune office equals accountability. Local presence can help with meetings; it does not guarantee delivery quality. Ask the same questions of remote and local vendors.
- Skipping legal review of the IP and data clauses. A contract is not a formality; it is the operating manual for what happens when things go wrong.
When to involve a specialist
Bring in a qualified lawyer before signing if the contract includes IP assignment, escrow, data-processing terms or liability caps. Bring in a security reviewer if the product handles sensitive personal data, payment information or regulated health data. Bring in an accountant or CFO if the contract includes multi-year support commitments or revenue-sharing terms.
This article is not legal, financial or security advice. Our pricing page explains how JUHENZA structures scope and quotes; selected work shows how project boundaries are documented in practice.
Frequently Asked Questions
What is the single most important question to ask a Pune software vendor?
Question 6: who owns the source code, infrastructure accounts and domain — and on what date. If ownership and access are not in writing, nothing else in the quote is fully under your control.
How do I compare two quotes with different scopes?
Use the normalisation worksheet above. Rewrite both quotes on the same template, then compare. If one includes integrations and acceptance tests and the other does not, you are not comparing the same product.
Should I ask for the code repository from week one?
Yes, for custom work. Repository access from week one lets you see progress, protects you if the relationship breaks down, and reduces the risk of a zip-file handover at the end. A vendor that refuses is a risk signal.
What is source-code escrow, and do I need it for an MVP?
Escrow is a third-party arrangement that releases source code to you if the vendor becomes insolvent, abandons the project or materially breaches the contract. For a small MVP with a short build, repository access and a clear IP clause may be sufficient. For a longer or business-critical build, discuss escrow with a lawyer.
How do I know if a Pune vendor is subcontracting my work?
Ask directly: "Will any part of this work be subcontracted, and if so, which parts and to whom?" Then ask to meet the people doing the work. If the answer is vague or the meeting is repeatedly postponed, assume subcontracting is part of the delivery model.
What data-protection questions should I ask before sharing customer data?
Ask where data is hosted, who can access it, how it is encrypted, which subprocessors are involved, how long it is retained, and what happens on a breach. If the vendor cannot answer, do not share personal data until a data-processing agreement is in place.
What if the vendor refuses to answer question 12 ("What would make you turn down this project?")?
A refusal is itself an answer. It suggests the vendor is prioritising the sale over fit. Treat it as a score of 1 for that question.
Is a Pune-based vendor always better for a Pune startup?
No. A Pune office can make in-person meetings easier, but delivery quality depends on the team, scope discipline and the contract — not the pin code. Remote studios can be stronger for focused MVP work. Ask the same twelve questions regardless of location.
Next Step
If you want a second opinion on a Pune software quote, or you want to turn your brief into a scoped written proposal, prepare a project brief. JUHENZA works remotely with founders across India, including Pune, and scopes acceptance criteria, deliverables and exclusions before quoting. You can also review application development services and how JUHENZA works.
References
- India Code — Digital Personal Data Protection Act, 2023.
- India Code — Copyright Act, 1957, including Section 17 on first ownership of copyright.
Score thresholds, the illustrative example and the contingency figure are planning aids, not guarantees. Legal references are informational and not legal advice.