Questions to ask a custom enterprise software development vendor before you sign

Ask a custom enterprise software development vendor five things: what the quoted price excludes, how they will integrate with your systems by name, who owns the code and infrastructure at the end, what happens in week nine when a requirement changes, and how you would exit. Vague answers to those five predict every problem that follows.

What follows is the full question set we would use if we were the buyer, arranged in the order a real procurement runs, with the answers that should reassure you and the ones that should not. Use it in a working session rather than as an email questionnaire; the useful signal is in how quickly someone reaches for a specific example.

What these questions are actually testing

You are not testing whether the vendor knows the technology. Almost everyone bidding can build a web application. You are testing three things that references and portfolios hide: whether they have delivered into an estate like yours, whether their commercial model survives contact with change, and whether they have thought about the twelve months after go-live.

The tell is specificity. A team that has shipped enterprise systems answers integration questions with interface types, failure modes and retry behaviour. A team that has not answers with the word integration. The same applies to migration, cutover and support.

One structural note before the list. Ask these questions of the people who would actually do the work, not only the account lead. If the vendor will not put the proposed technical lead in front of you before signature, that is itself an answer.

It also helps to know what you are not testing. Team size is not a quality signal, and neither is a long client logo wall. The question behind every question below is simply whether this team has been in the room when a cutover went wrong, and what they changed afterwards.

The five questions that do most of the work

• What does this price exclude? A confident vendor has a written exclusions list covering data migration, environments, penetration testing, training and third-party licences. A vendor who says the price covers everything either has not read your estate or is planning to recover the gap through change requests.
• Walk me through integrating with our named systems. Name the actual systems: the ERP, the payment gateway, the identity provider, the reporting warehouse. Listen for interface type, authentication, rate limits, idempotency and what happens when the far side is down.
• Who owns the code, the infrastructure and the documentation on the last day? The answer should be you, unambiguously, with repositories in your organisation from day one rather than transferred at the end. Our position on code and IP ownership is that the client owns everything, including deployment configuration.
• A requirement changes in week nine. What happens? You want a named change process, a published rate, and an honest statement of which changes are absorbed and which are not. Fixed price with no change mechanism is not reassurance; it is a dispute scheduled for later.
• How would we leave? Ask for the exit clause, the handover artefacts, the notice period and whether they will train an internal team. A vendor comfortable with this question is a vendor who expects to be kept for good reasons.

How to read the answers

Sequencing the conversation

Before the proposal

Establish fit. Ask what size of programme they normally run, which systems they have integrated with in the last two years, and whether they have worked under your regulator. A vendor whose median project is a marketing site will struggle with a finance integration, and it is kinder to both parties to find that out early.

While the proposal is being written

Establish method. Ask how scope is locked and what a scope lock means in their contract. Ask whether the estimate is bottom-up from a task breakdown or top-down from a similar project. Ask what discovery they need before the number is trustworthy, and say yes to it if the answer is reasonable.

Before signature

Establish accountability. Get the delivery lead's name in the statement of work, the escalation path with its timeframes, the acceptance criteria for each milestone, and the support contract alongside the build contract rather than after it. This is also the moment to ask whether the vendor works to a recognised information security standard such as ISO/IEC 27001, and what evidence they can provide.

What should you ask about money?

Ask for the numbers you will still be paying in year two, not just the build. Our published starting prices exist precisely so this conversation can start from a real figure: custom and enterprise software development runs from $24,500 or ₹16,00,000 to $175,000 or ₹1.2 crore, and post-launch Care Plans run from $1,000 or ₹68,000 per month for Essential, through $2,500 or ₹1,60,000 for Standard, to $5,250 or ₹3,40,000 for Enterprise with a one-hour response and a named engineer. All of it sits on the pricing page.

Three commercial questions matter more than the headline rate. What is the change-request rate, and is it in the same document as the fixed price? What happens to the price if our decisions are slow? And what do we pay during hypercare? The companion post on hidden costs in custom enterprise software development lists the lines these questions are designed to surface.

Ask one more thing before the contract goes to legal: what would make you walk away from this project. Every experienced delivery team has a list, usually including an absent decision maker, a data set nobody will let them see, or a deadline set by an event rather than by the work. A vendor who names their conditions is telling you where the project is fragile, which is exactly the information a statement of work should be built around.

When this interrogation is the wrong approach

A twenty-question due diligence pack is disproportionate for a $20,000 engagement, and it filters out small specialist teams who are often the best value on narrow work. If the project is small, bounded and reversible, a paid two-week discovery with a real deliverable tells you more about a vendor than any questionnaire, because you see how they work rather than how they write.

The other failure mode is using these questions adversarially. The goal is a working relationship in which bad news travels fast. If your procurement process trains the vendor to give defensive answers, you will get defensive answers for the next eighteen months too. Ask hard questions in a tone that invites honesty, and treat a vendor who volunteers a risk as a better sign than one who volunteers none. Signs your vendor is out of their depth covers what to watch for once work is under way.

Finally, ask how they will work with your own engineers. About half our work is paired with an internal team, with documented handover, and the shape of that arrangement should be agreed at the start rather than improvised at the end. If your intention is to take the system in-house after twelve months, say so in the first meeting and watch the reaction closely.

What a good answer looks like in practice

When a university asked us about replacing a fifteen-year-old ERP, the answer to the migration question was not a plan to migrate everything. It was a proposal to put an API layer over the existing system, build new capability beside it, and move functions across one at a time so the institution could keep running through an academic term. That is what a delivery-shaped answer sounds like, and the legacy ERP modernisation case study records how it went.

Your pre-signature checklist

• Written exclusions list attached to the quote
• Integration inventory with interface type named for each system
• Repositories and cloud accounts in your organisation from day one
• Change-request process and rate card inside the main contract
• Named delivery lead and technical lead in the statement of work
• Acceptance criteria defined per milestone, not per project
• Support contract, response targets and monthly hours agreed before build starts
• Exit clause with handover artefacts listed

Related reading

What to put in a custom enterprise software development RFP helps you ask better questions in writing, how to compare proposals when nobody quotes hourly deals with comparing the answers you get, and a security questionnaire for AI vendors provides the security half of the diligence pack. When you are ready to run this conversation with us, the contact page is the starting point.

The vendor who tells you what their price excludes is usually the one whose price holds.