What to Ask a Dev Partner at the Proposal Walk-Through

For: Owner or COO of an Indian SMB — manufacturing, logistics, retail, or services — who has received two or three proposals from development partners, scheduled a 60-minute walk-through call, and has no idea which questions will actually expose the risks before they sign a ₹15–50L contract

The proposal walk-through is a scoping interview disguised as a sales pitch. Your job in those 60 minutes is not to nod along to the slide deck — it is to ask sixteen specific questions that force the vendor to expose how they handle IP transfer timing, scope disputes, milestone payments, and what happens when the project goes sideways. Below is the interview script, question by question, with what a good answer sounds like and what should make you walk away.

Some context on why this matters: 78% of software projects experience scope creep, and the median cost overrun for large IT projects exceeds 45% of the original estimate. For an Indian SMB signing a ₹15–50L contract — where MSMEs operate at just 18% of large-enterprise productivity — a failed engagement is not a line item. It is existential.

Before the call: what to have in front of you

Print the proposal. Highlight every clause containing the words ownership, assignment, milestone, acceptance, change request, warranty, and termination. If those words don't appear, that's your first red flag — you're looking at a marketing document, not a contract. Ask for the Master Services Agreement and Statement of Work in advance. If the vendor sends only the proposal deck and says the MSA comes after signing the LOI, stop there.

Block 1: IP ownership and code custody (questions 1–4)

1. On what exact date does IP ownership transfer to us — signing, per-milestone, or final payment?

Why it matters: Under Section 17 of India's Copyright Act, 1957, the developer is presumed to be the first owner of software copyright unless a written assignment says otherwise. Most Indian dev contracts transfer ownership only on final payment. That means if you dispute the last invoice, the vendor legally owns the code your business runs on.

Good answer: "Ownership transfers on a per-milestone basis as each milestone is paid and accepted, using a hereby assigns clause."

Red-flag answer: "Standard industry practice — ownership transfers on final payment." Or worse: "Don't worry, we always hand over the code."

2. Does the assignment clause use "hereby assigns" or "agrees to assign"?

Why it matters: The phrasing decides when ownership legally transfers. "Hereby assigns" is immediate. "Agrees to assign" is a future promise — enforceable in theory, litigable in practice.

Good answer: They know the difference and their contract uses "hereby assigns."

Red-flag answer: They don't know, or they say their lawyer will explain later.

3. Where does our source code live during development, and when do we get repository access?

Why it matters: If code sits only in the vendor's private GitLab, a dispute means you have nothing to move to another team. Repository access from day one is the operational side of IP ownership.

Good answer: "We create a repository in your organization's GitHub or GitLab account on day one. Our engineers get contributor access. You own the container from the start."

Red-flag answer: "We'll hand over a zip file at the end." Run.

4. What third-party code, libraries, and open-source licences will be in our final build?

Why it matters: A GPL-licensed component embedded in your proprietary product forces you to open-source the whole thing. Copyleft licences are silent landmines.

Good answer: "We maintain a software bill of materials, avoid copyleft licences for proprietary work, and will share the list before we begin."

Red-flag answer: Vague reassurance that "everything is standard open source."

Block 2: Scope, change requests, and the price of "one small thing" (questions 5–8)

5. What specifically triggers a change request, and who signs off?

Why it matters: Scope creep causes 33% of software project failures. If "change request" is loosely defined, either you get nickel-and-dimed for every clarification, or the vendor absorbs everything and cuts corners on quality.

Good answer: "Anything that changes an acceptance criterion in a signed user story triggers a written change request. Clarifications inside existing criteria don't. Sign-off is a named person on each side, via email, within 48 hours."

Red-flag answer: "We'll figure it out as we go" or "Everything is handled flexibly."

6. Show us a change request from a past project — the actual document.

Why it matters: Talk is cheap. A real CR shows whether the vendor's process is mature or improvised.

Good answer: They share a redacted CR with hours, cost, impact on timeline, and both signatures.

Red-flag answer: "We can't share client documents." A redacted example is always shareable.

7. What is your definition of "done" for a milestone?

Why it matters: 39% of project failures trace to unclear requirements. "Done" is the single most disputed word in software contracts.

Good answer: "Code merged to main, deployed to staging, acceptance test cases passing, documentation updated, and your team has signed the acceptance checklist. All five, not three of five."

Red-flag answer: "When the feature works."

8. If we discover a defect a week after milestone acceptance, is fixing it a warranty item or a change request?

Why it matters: This is where the money leaks. A vague warranty clause means every bug becomes a billable line item.

Good answer: "Defects against the signed acceptance criteria are warranty items, fixed free within a defined window — usually 30 to 90 days post-milestone. New behaviour is a CR."

Red-flag answer: No warranty period, or warranty tied only to "critical bugs" without defining critical.

Block 3: Payments, milestones, and leverage (questions 9–11)

9. What is the payment schedule, and what percentage is held until final acceptance?

Why it matters: A 40% upfront, 60% on delivery structure gives the vendor no incentive to finish cleanly. A well-structured schedule keeps meaningful leverage until the end.

Good answer: "15–20% mobilisation, then milestone-linked tranches, with 10–15% held for a defined post-launch stabilisation period."

Red-flag answer: Over 50% upfront, or no retention.

10. If we pause the project for 60 days for business reasons, what happens?

Why it matters: Real projects pause — a funding round, a regulatory change, a founder illness. The contract's answer to "pause" tells you how the vendor treats you as a partner versus a revenue line.

Good answer: A defined pause clause with a modest reactivation fee and a clear window (usually 60–90 days) before the contract can be terminated by either side.

Red-flag answer: "Full payment continues" or silence in the contract.

11. What drives the price and timeline in your proposal, and what would move them 20% in either direction?

Why it matters: A vendor who can articulate the cost and duration model — integrations, data migration, compliance scope, team seniority mix, unknowns in your existing systems — understands your project. One who can't is guessing. The variables that matter most are usually: number of external integrations, whether you have clean existing data or need migration, whether the deployment needs to hit a compliance bar (HIPAA, RBI, SOC 2), and how much of the workflow is already documented.

Good answer: They walk through the drivers, name the two or three that dominate your specific project, and are explicit about what they've assumed versus what they'd need to discover.

Red-flag answer: A confident single number with no sensitivity analysis.

Block 4: Team, continuity, and the people actually writing your code (questions 12–14)

12. Which named engineers will be on our project, and what is their allocation percentage?

Why it matters: "A team of eight" often means one senior 20% of the time and rotating juniors. Named allocation with percentages is the only honest way to read team capacity.

Good answer: A staffing table with names, roles, allocation %, and start/end dates.

Red-flag answer: Only role titles, no names, or promises to "assign the best people."

13. What is your policy if a key engineer leaves mid-project?

Why it matters: Attrition in Indian services firms runs 15–25% annually. Your project will lose someone. The question is how the vendor absorbs the hit.

Good answer: "Two-week handover overlap paid by us, not you. Documentation standards enforced weekly so any engineer can pick up the work."

Red-flag answer: "We'll assign a replacement." No handover process, no cost ownership.

14. Can we speak to the engineering lead, not just the account manager, before signing?

Why it matters: The account manager sold you the deal. The engineering lead will decide whether it succeeds. A 20-minute call with the lead surfaces gaps the proposal hides.

Good answer: Yes, and they schedule it within a few days.

Red-flag answer: "The lead will be introduced after signing."

Block 5: What happens after launch (questions 15–16)

15. What does post-launch support include, for how long, and at what response time?

Why it matters: Most SMB projects treat "support" as an afterthought and discover in month two that critical bug fixes cost extra. The support terms determine your real total cost of ownership.

Good answer: A defined SLA — response time by severity, hours of coverage, whether it's included or a separate AMC, and what triggers escalation.

Red-flag answer: "Three months of free support" with no severity definitions or response times.

16. If we decide to move to another vendor in year two, what does the handover look like?

Why it matters: A vendor confident in their work will describe a clean exit. A vendor who plans to trap you will get uncomfortable.

Good answer: "We hand over the repository, infrastructure credentials, architecture documentation, and offer a paid two-week transition window to the next team. It's in the contract."

Red-flag answer: "No one has ever left us," or a defensive tone.

How to read the room

Watch for three patterns during the walk-through. First, the vendor who answers every question by pointing to the proposal PDF is a vendor whose contract is the proposal — thin. Second, the vendor whose answers change depending on which stakeholder is speaking has not aligned internally on how they deliver. Third, the vendor who pushes back on a question — thoughtfully, with reasoning — is often the strongest signal of a real partner. You want someone who will disagree with you productively during delivery, not nod through discovery and surprise you at UAT.

How CodeNicely can help

We've been on the vendor side of hundreds of these walk-throughs since 2017. When we built GimBooks — a YC-backed accounting SaaS for Indian MSMEs — the client came to us after a previous partner had shipped a codebase they couldn't legally extract because of an ambiguous assignment clause. We rebuilt the platform with milestone-linked IP transfer, repository ownership from day one, and a documented handover protocol from the start of the engagement. That's the operating model we bring to every SMB and scaleup contract, whether it's legacy modernisation, a custom platform, or embedding AI into existing operations. If you're comparing proposals right now and want a second read on the contract terms — not the price, the terms — that's a conversation we're happy to have. We are not the right fit if you want a fixed-price black box with no visibility into the build; we work best with clients who want to see the code, the sprints, and the tradeoffs weekly.

One note: nothing above is legal advice. Before signing a ₹15–50L contract, a lawyer familiar with Indian software contracts should review the IP assignment, indemnity, and termination clauses against your specific business.

Frequently Asked Questions

What are the biggest red flags in an offshore dev proposal in India?

Four stand out: IP assignment only on final payment, no named engineers in the staffing plan, no written change request process, and vague warranty terms. Any one of these turns a ₹15–50L contract into a ₹25–70L one, or worse — a codebase you can't legally extract. Ask about all four in the walk-through.

How much should I budget for a custom software build with an Indian dev partner?

The honest answer is: the cost model depends on integrations, data migration scope, compliance requirements, and team seniority mix, and any vendor quoting a single confident number without discovering those hasn't scoped your project. Ranges in the market span widely — a two-integration MVP with no data migration and no regulated-industry compliance sits at one end; an ERP replacement with historical data and RBI or HIPAA scope sits far further out. To turn a range into a quote, you need a scoping conversation covering integrations, data state, compliance, and team mix. That's the conversation to have with a shortlisted partner before you sign.

How long does a typical SMB software project take in India?

The same variables that drive cost drive timeline: integration count, data readiness, and compliance scope. Standish's CHAOS data shows 40–50% of software projects finish late, so any timeline should be read as an estimate with named risks, not a promise. Ask the vendor which two or three assumptions in their timeline are most likely to slip, and what would trigger a slip — that answer tells you more than the number.

Who owns the code if we don't have a written IP assignment clause?

Under Section 17 of India's Copyright Act, the developer is the first owner by default. Without a signed assignment, the outsourced agency or contractor legally owns the copyright in the code your business paid to build. This is not a theoretical risk — Indian courts have affirmed it repeatedly. Get the assignment clause explicit, and have a lawyer confirm the wording before you sign.

Should I ask for references, and what should I ask them?

Yes, and skip the happy-path questions. Ask the reference: what went wrong on the project, how the vendor handled it, whether they went over budget or timeline, and whether they'd sign with the same vendor again for a different project. A reference who only says nice things is either coached or was on a project too small to stress-test the partnership.