Questions to ask a data analytics application development vendor before you sign

Ask a data analytics application development vendor five things: how they prove a number matches your source of truth, who owns the code and infrastructure, what the system costs to run monthly, what happens when a source schema changes, and how you exit. A vendor who has shipped answers all five with specifics in under a minute each.

Below are the questions grouped by the stage at which to ask them, with the signal a strong answer carries and the evasion to watch for. Use them in order; the first call disqualifies more candidates than the last one does.

Round one: questions for the first call

The goal of the first call is not to evaluate a proposal. It is to find out whether the vendor thinks in data or in dashboards. Ask these four and listen for whether they immediately start asking you questions back.

• Which of your last three analytics builds had the messiest source data, and what did you do about it? A vendor who has done this work will describe a specific mess: a currency field that was text, a duplicate customer key, a migration that renamed branch codes. A vendor who has not will describe their process.
• How do you define a metric so two departments cannot disagree later? You want to hear about written definitions with filters and time grain held in version control, not about a workshop.
• What do you do when the business asks for a dashboard that the data cannot honestly support? The right answer is that they say so and propose what the data can support. Any answer that involves building it anyway tells you how the project will end.
• Who on your team will actually write this code, and are they on other projects? Named people, with a stated allocation. Agencies that answer this vaguely are selling you a sales team.
• What would make you tell us not to build this? Every honest engineering firm has a version of this answer. A firm with none has never turned down work, which means it has taken work it should not have.

Round two: the questions that separate shortlisted vendors

By this stage the difference between bids is rarely capability and usually assumptions. These questions surface the assumptions.

Round three: the contract questions

Contract review is where politeness costs money. The three clauses below are the ones that decide whether you have bought a system or rented a dependency, and all three are easier to fix before signature than at renewal.

Ownership, in writing

The contract should state that you own the source code, the infrastructure definitions, the data models, the metric definitions and the documentation, and that they live in your accounts throughout. This is the clause most often softened in negotiation and the one that costs most to have got wrong. Our own position is that clients own all of it, which is what code and IP ownership means as a contractual term rather than a slogan.

Commercial model and what changes it

Ask what specifically triggers a change order, and get the list. "An additional source system" and "a change to an agreed metric definition after sign-off" are reasonable triggers. "Anything not explicitly listed" is not. Fixed price is safe when the scope is genuinely locked; if the data section is still vague, time and materials with a cap is the more honest instrument, as fixed price vs time and materials sets out.

Security, at a stated level

Rather than accepting a general assurance, ask the vendor which level of the OWASP Application Security Verification Standard the application will be built to, since it defines graded, testable requirements for authentication, access control and logging. Then ask who verifies it. For the broader vendor review, a security questionnaire for vendors covers data handling, subprocessors and incident response.

How to test the answers rather than collect them

Answers are cheap. Two exercises are not, and both are worth running before signature.

First, give each shortlisted vendor a sample extract from your messiest source system and ask what they would do with it. You are not asking for free work; a page of observations is enough. The vendor who spots the duplicate keys and the date-format inconsistency in an afternoon is the one who will spot them in week three rather than week nine.

Second, ask for a reference on comparable data volumes, then ask that reference two questions: what went wrong, and how it was handled. Every project has an answer to the first. A reference who cannot recall anything going wrong was not close enough to the project to be useful.

What a good answer sounds like in practice

When an operator asked us how reporting would work across a live dispatch operation, the useful part of the answer was not an architecture diagram. It was that depot managers would each see only their own depot, that the numbers would be reconciled against the dispatch system nightly, and that a stale feed would show a banner rather than yesterday's figures presented as today's. The dispatch platform and field apps build describes the system those constraints produced.

That is the texture to listen for. Specific rules, specific failure behaviour, specific reconciliation. A vendor who answers at that resolution on a first call has built the thing before; one who answers with methodology slides is describing a process rather than a system.

When this due diligence is disproportionate

If you are buying a two-week reporting layer over one clean database, running three rounds of vendor questions costs more than the build. Ask the ownership question, the running-cost question and the exit question, then get on with it. The full process earns its keep above roughly $20,000 or ₹13,00,000 of build, or wherever a regulator, an auditor or a customer contract is involved.

It is also disproportionate when you already know the answer is buy rather than build. If an off-the-shelf tool over your warehouse covers the need, the vendor conversation you should be having is about integration, not application development. That trade-off is worked through in build or buy for analytics applications.

What the numbers should look like

Use price as a consistency check on the answers rather than as a ranking. Data and analytics application development at Eazyware starts at $14,000 or ₹8,80,000 and reaches $56,000 or ₹36,80,000 for a multi-source governed platform, and post-launch care runs from $1,000 or ₹68,000 a month at the Essential tier to $5,250 or ₹3,40,000 at Enterprise with a named engineer and one-hour response. The bands are published on the pricing page. A bid well under the band with the same stated scope is not a discount; it is a different set of assumptions you have not been shown yet.

Checklist before you sign

• Reconciliation tests named in the acceptance criteria, not in a warranty clause
• Ownership of code, infrastructure, models and documentation stated explicitly
• Monthly running cost estimated at your volumes, with assumptions listed
• Change-order triggers enumerated rather than defined by exclusion
• Named engineers with stated allocation for the delivery period
• Support tier, hours of cover and response targets agreed before go-live
• A handover deliverable that includes one of your engineers deploying a change
• Two references on comparable data volumes, asked what went wrong

Related reading

What to put in a data analytics application development RFP covers the document that produces comparable bids in the first place, the hidden costs of data analytics application development prices the lines a quote leaves out, and what a fixed-price quote should contain shows how to read a proposal once it arrives. If you would like these questions answered about our own work, talk to us.

The questions that matter are the ones with a number, a name or a document in the answer; everything else is a brochure.