Choosing a development partner is a decision made with very little information, usually under time pressure, by someone who will have to live with the consequences for years. Price, timeline and technology stack dominate the conversation because they are easy to compare across proposals. They are also the three things most likely to change. These are the questions we would ask instead, and we include them knowing they are uncomfortable to answer.
On the people: who specifically will do the work, and are they the same people in this meeting? A proposal presented by senior architects and delivered by whoever is on the bench is the single most common disappointment in this industry. Ask for names and roles. Ask what happens if one of them leaves mid-project. And ask what the team looks like in month six, because staffing usually thins once the interesting architectural work is finished and the unglamorous part begins.
On the work itself: what does done mean, and who decides? Ask to see the acceptance criteria format they use. Ask how a change request is handled - whether it is a conversation or a contract negotiation - because you will have change requests, and the answer tells you what the relationship becomes under pressure. Ask what their automated test coverage looks like on a comparable project, and whether you get the test suite.
On ownership: who owns the code, the infrastructure accounts and the domain? This sounds procedural until the day you want to leave. A partner who holds your cloud account, your repository or your DNS holds more than a contract. The correct answer is that everything is provisioned in your name from day one, and you should verify it rather than accept it as an assurance.
On evidence rather than promises: ask for a reference client in a similar industry and actually call them. Ask what their last project cost against the original estimate, and why it differed - every honest answer to that question involves a number that moved. Ask how they handled a security incident they did not cause. A partner comfortable with all three is worth a long look; deflection on any of them is itself information.
On the ending: what does handover look like, and what does it cost to leave? Ask what documentation exists at the end - not whether documentation is included, but what specifically. Runbooks, architecture decision records and an operational handover session are different things from a README. And ask directly what happens if you want to bring the work in-house in year two. A partner who has thought about that question and answers it plainly is telling you they expect to be kept for reasons other than lock-in.
A note on the Bengaluru market specifically, since that is where we sit: the density of firms here means you can afford to be selective, and the range in quality between the best and worst quote you receive will be far wider than the range in price. Two proposals within ten per cent of each other on cost can differ enormously in who writes the code and what you own at the end. The questions above are how you tell them apart before you sign rather than after.
