In brief
- Most failed data projects fail on people and process, not technology. Ask who will actually write the code and how correctness will be proven.
- Good vendors propose a small first milestone with acceptance criteria. Vendors who quote the whole roadmap on day one are guessing.
- Compare proposals on the same scope, seniority, testing, documentation and support. A low headline price that excludes reconciliation and monitoring is not low.
Choosing a data engineering partner is difficult because the output is invisible until it is wrong. A pipeline can run green for months while quietly dropping records, and a dashboard can look finished while the numbers underneath it are unreliable. The questions below are the ones we would want a client to ask us, grouped by what they reveal. Use them as a checklist in your first conversations with any remote consultancy, including this one.
People
1. Who exactly will do the work, and can we meet them before we sign?
Why it matters: Proposals are often written by senior people and delivered by junior ones. A good answer: named engineers, their backgrounds, and a call with them before commitment. Be cautious if the main contact will be an account manager rather than an engineer.
2. How senior is the person who will review the code and the data?
Why it matters: Data work is full of judgment calls about grain, deduplication, late-arriving records and business definitions. A good answer: a specific senior engineer accountable for review, with examples of the kind of issues they catch.
3. What happens if that person is unavailable?
Why it matters: Continuity is the real difference between a consultancy and a freelancer. A good answer: documented systems, a second engineer familiar with the work, and a handover process, not just "we have a big team".
Method
4. What would you propose as the first milestone, and how would we know it worked?
Why it matters: A vendor who cannot narrow the problem cannot estimate it. A good answer: one dependable reporting flow, one source integrated end to end, or one bounded review, with written acceptance criteria such as "matches the finance ledger to within 0.1% for the last twelve months".
5. How will you prove the numbers are right?
Why it matters: "The job succeeded" and "the data is correct" are different statements. A good answer: reconciliation against source records, checks for freshness and completeness, tests for edge cases such as empty periods and reprocessed records, and a plan for what happens when a check fails.
6. What will operating this look like after you leave?
Why it matters: Pipelines are run far longer than they are built. A good answer: schedules and ownership documented, alerts that reach a human, recovery steps for common failures, and source-to-report mappings your own team can follow.
Commercials
7. What does the price include, and what does it exclude?
Why it matters: Testing, documentation, monitoring and handover are where cheap proposals save money. A good answer: an itemised scope that names these explicitly. Ask two vendors to price the same written scope and the comparison becomes meaningful.
8. Who owns the code, the infrastructure and the data models?
Why it matters: Some vendors deliver into their own accounts and charge to release them. A good answer: everything in your repositories and cloud accounts from day one, with ownership stated in the agreement.
9. How do you handle changes in scope?
Why it matters: Requirements will change once real data appears. A good answer: changes are written down, estimated and agreed before they are built, and assumptions that prove wrong are raised immediately rather than absorbed silently or invoiced later.
Working model
10. Which hours will you overlap with us, in our local time?
Why it matters: "We adapt to your timezone" is not a commitment. A good answer: a specific recurring window, the meetings that live inside it, and how progress is communicated outside it. See our timezone playbook for what realistic windows look like.
11. Where will decisions and progress be recorded?
Why it matters: Remote work fails when decisions live in someone's memory. A good answer: your tools, your wiki, your ticketing system; written standups and decision records you could forward to a stakeholder without editing.
Evidence
12. What can you show us, and what can you not?
Why it matters: Confidentiality limits what any consultancy can share, but it does not eliminate evidence. A good answer: verified credentials with links, anonymised descriptions of comparable work, a sample scope document or runbook, and honesty about what is under NDA. Be wary of logos without context and of testimonials that cannot be attributed.
How to run the comparison
- Write one page describing the outcome you need, the systems involved, approximate data volumes and your working hours.
- Send the same page to each shortlisted vendor and ask for a first-milestone proposal, not a roadmap.
- Score the proposals on the twelve questions above before you look at the price.
- Only then compare prices, adjusting for what each proposal excludes.
Vendors who respond to a one-page brief with specific questions of their own are usually the ones who will find the problems in your data before your finance team does.
Frequently asked questions
Should we start with a data audit or go straight to building?
If you already have pipelines and reports that people distrust, a short bounded review is usually the best first engagement: it produces a prioritised list of what is actually broken. If you are starting from spreadsheets and exports, build one dependable reporting flow end to end; it teaches both sides more than an audit would.
Is a remote consultancy in India a reasonable choice for a US or UK company?
Yes, provided the overlap hours, communication practices and accountability are explicit. The structural cost advantage is real because you are not paying for offices and account layers, but it only helps if the seniority and the working model are right. Apply the same twelve questions you would apply to a local firm.
What should we share before the first call?
The report or workflow you want to improve, the source systems, rough data volumes, the tools you use today and the refresh frequency you need. A description or a sanitised example is enough; credentials are never needed for an enquiry.