Questions to ask a software product development company vendor before you sign
What should you ask a software product development company vendor?
Ask the questions whose answers cannot be improvised: who owns the code, what happens when scope changes, which environments and licences you pay for, how the team escalates at two in the morning, and which named engineers do the work. Vague answers predict a difficult project better than a portfolio does.
Ask the questions whose answers cannot be improvised: who owns the code, what happens when scope changes, which environments and licences you pay for, how the team escalates at two in the morning, what the handover contains, and which named engineers will actually do the work. Vague answers here predict a difficult project more reliably than a portfolio does.
Below is the question bank we would use if we were the buyer, grouped by what each answer reveals, with a table of what a good answer and a warning sign sound like, the commercial answers you should expect in writing, and the small number of questions that are not worth the meeting time.
Why the portfolio tells you the least
Every software product development company can show you finished screens. Screens are the output of the easy part. What you are buying is the behaviour of a team under conditions that have not happened yet: an integration that turns out to be undocumented, a scope change three weeks from launch, a production incident on a public holiday, and the day your internal team takes the system over.
A portfolio cannot answer any of those. Direct questions can, because an answer that has been lived sounds different from an answer that has been prepared. A vendor who has shipped will reach for a specific mechanism, a named artefact or a number. A vendor who has not will reach for adjectives.
One more framing point. You are not trying to catch anybody out. You are trying to find out whether the way this firm works fits the way your organisation makes decisions, because most failed engagements fail on that mismatch rather than on engineering ability.
Eight questions to ask before you sign
- Who owns the code, the infrastructure and the design files, and from what date? The answer should be you, from the first commit, in writing. Eazyware clients own code, infrastructure, design files and documentation outright, which matters at acquisition diligence and again if you change partner.
- Which named engineers will be on this project, and what else are they on? Ask for names and allocation percentages. Pitch teams and delivery teams are different populations at a surprising number of firms, and finding that out in month two is expensive.
- How do you estimate, and what happens commercially when scope changes? You want a stated mechanism: a fixed scope with a written change process, or a rate card with a cadence for re-forecasting. Anything else becomes an argument at the worst moment.
- Which environments exist, and whose accounts pay for cloud and licences? The answer should place cloud and third-party accounts with you, so billing is visible and you can leave without a migration. Ask how many non-production environments the estimate assumes.
- What does the test and evaluation suite look like at handover? For conventional software, ask about automated coverage of the critical paths and how a release is verified. For anything with a model in it, ask for evaluation suites with a scored dataset, not a demo.
- What is the escalation path and response target after launch? You want hours of cover, a response time, a named person and a runbook. Support that is described as best efforts is an unpriced obligation for your own team.
- Which security standard will the build be verified against? A credible answer names something. The OWASP Application Security Verification Standard defines levels of verification requirements that you can write into a contract and test against rather than trusting a checklist.
- What does exit look like? Ask for the handover contents, how long it takes, and what it costs. A firm confident in its work will describe documentation, a walkthrough and a support taper without flinching.
Good answer versus warning sign
| Question | A good answer sounds like | A warning sign sounds like |
|---|---|---|
| Ownership | Yours from commit one, stated in the MSA, including prompts and infrastructure | Ours until final payment, or licensed back to you |
| Team | Three named people, seventy per cent allocated, CVs attached | A pod of senior engineers, allocated as needed |
| Estimation | Fixed scope, fixed price, a written change note process | We are agile, so we estimate as we go |
| Environments | Dev, staging and demo, in your cloud account, listed in the SOW | We will sort out environments during the build |
| Testing | Automated coverage of named critical paths, plus a release checklist | Our QA team tests everything manually before release |
| Support | 24x5 cover, four-hour response, named engineer, runbook at handover | We are always available on WhatsApp |
| Security | ASVS level named, penetration test budgeted before launch | The platform we use is secure by default |
| Exit | Two weeks of documented handover and a taper, priced in advance | Nobody has ever asked us that |
Two practical notes on how you ask. Put the questions to the person who will lead delivery, not the person selling the work, and ask for one answer in writing afterwards. A firm that cannot get its delivery lead into a pre-sales call is telling you how available that person will be later. Then take two reference calls and ask the referees a single question: what went wrong, and how did the vendor behave when it did.
What should the commercial answers be?
Ask for the numbers in writing and compare them against a published benchmark. Eazyware's product and platform development programme is a fixed-price engagement from $42,000 or ₹28,00,000 up to $175,000 or ₹1.2 Cr, and the position within that band follows integration count and governance load rather than screen count. Sprint Zero is ten days, ProofRun is three weeks, a Launch 6 MVP is six weeks, and most scoped builds run eight to sixteen weeks.
Support should be quoted as a tier rather than as goodwill. Ours run at $1,000 or ₹68,000 a month for business hours in IST, $2,500 or ₹1,60,000 for 24x5 with a four-hour response, and $5,250 or ₹3,40,000 for 24x7 with a one-hour response and a named engineer, all listed on the pricing page. If a vendor cannot put a response time next to a number, they have not run production software for someone else.
If a vendor cannot scope confidently, a paid discovery engagement is the right answer rather than a padded fixed price. A ten-day discovery sprint at $3,250 or ₹2,00,000, credited against the build, produces the architecture, the scope and the estimate. Paying for certainty is cheaper than buying a number somebody guessed.
The three answers we would press hardest on
Ownership, said plainly
Press until the answer covers source code, infrastructure-as-code, design files, documentation, third-party accounts and any model prompts or configuration. Partial ownership shows up as a dependency you only discover when you try to leave, and the point of asking early is that it costs nothing to fix in a contract and a great deal to fix in a migration.
What happens when scope changes
Every project changes. The question is whether the change process is written down. Ask to see a change note from a previous project with the commercial terms redacted. Fixed-price work needs a locked scope and a clear route to vary it; the discipline behind that is described in fixed price, fixed date: how we make it work.
Who answers at two in the morning
Ask what happened the last time a production system this firm built went down. A real answer includes a timeline, a root cause and what changed afterwards. Then ask who owns the runbook and whether your team is trained on it, because a support arrangement that depends on one person's phone is not a support arrangement.
Questions that waste the meeting
Due diligence has diminishing returns, and three questions come up constantly while telling you almost nothing. Swapping them for sharper versions costs nothing and buys you a real signal.
How many developers do you have. Headcount is not capacity, and a large firm will still put a small team on your project. Ask instead which three people are on yours and what else they are committed to.
Which technologies do you specialise in. Almost every competent team can build your product in several stacks. The better question is what they would choose for your constraints and why, and what they would refuse to use. A firm that names something it avoids is showing you judgement.
Have you built something exactly like this before. Close analogues are comforting, but the useful version is narrower: have you integrated with this specific system, migrated data of this age, or shipped under this compliance regime. If the honest answer is no, a three-week ProofRun on the riskiest part is worth more than a reassuring case study.
What a straight answer looks like
A university came to us with a fifteen-year-old ERP and a governing body that would not approve a rewrite. The answer they needed was not a portfolio; it was a sequence, a migration plan and a way to run old and new side by side while departments moved across. The engagement is described in the legacy ERP modernisation case study, and the thing that made it work was agreeing the awkward answers before the contract rather than after.
That engagement also shows why the ownership and exit questions matter for public bodies and large corporates in particular. Their procurement teams will ask them of you during the next tender, and the only comfortable position is one where the answers were settled at the start. If you are also weighing hiring instead, Eazyware versus building an in-house team sets out the same questions applied to a permanent team.
Related reading
What to put in a software product development company RFP turns these questions into a document you can send, the hidden costs of software product development company covers the lines a quote leaves out, and a security questionnaire for AI vendors gives you the security section in full.
Ask the awkward questions while you still have the leverage of not having signed anything.
Frequently asked questions
What is the single most important question to ask a development vendor?
▾
Who owns the code, infrastructure, design files and documentation, and from what date. If ownership is conditional or partial, every other answer is worth less, because you cannot change partner, pass an acquisition diligence or move hosting without a negotiation you did not plan for.
How do I check a vendor can actually deliver rather than just pitch?
▾
Ask for the names and allocation of the engineers on your project, a change note from a previous engagement, and an account of the last production incident they handled, including root cause and what changed afterwards. Prepared answers and lived answers sound noticeably different.
Should I pay for a discovery phase before the build?
▾
Yes, when scope is uncertain. A paid discovery produces an architecture, a scope and a defensible estimate rather than a guess wrapped in contingency. Eazyware's ten-day discovery sprint is $3,250 or ₹2,00,000 and is credited against the build, so certainty costs you nothing if you proceed.