How Much Does a Data Project with a Consultancy Cost? Variables, Ranges, and What Nobody Tells You
This article starts with something you may have already noticed: nobody talks about pricing in data consulting. Not in LATAM, not in the US, not anywhere. Under the official argument that “every project is unique” (which, to be fair, is true), the industry generates a lack of transparency that we believe benefits no one.
We believe that talking about money with clarity is an act of respect. If you are reading this article weighing your options and cannot judge what is a reasonable investment and what is not, it is simply because no one in the industry has taken the time to explain it.
When someone asks “how much does a project cost?”, what they’re really asking is one of these three things:
- Can I afford to do this?
- Is what I am paying excessive, or is this normal?
- What exactly am I buying for this investment?
You won’t find a pricing table here (and by the end of the article you’ll understand why one wouldn’t make sense), but you will find the variables that actually move the number up or down. Our goal is that when you finish reading, you can have a pricing conversation with any consultancy (ours included) without feeling like you are negotiating blindfolded.
The Five Variables That Determine the Cost of a Data + AI Project
1. Your Data Maturity
Would you trust a restaurant that doesn’t properly track the expiration dates of its ingredients? Would you buy clothes from a store where the shirts are crumpled up with sizes all mixed together? We’re guessing that’s a hard no. Yet, you’d be surprised how many companies do something remarkably similar with their data (the richest and most exploitable raw material of this century).
This point is a big part of what determines project effort. Two companies of the same size with the same “AI project” can face wildly different costs depending on what lies underneath. Meaning: if your data is consolidated, has traceability, reasonable quality, and someone who understands it, the build can start almost immediately. If it’s scattered across five different places, you don’t know where or how things connect, and the documentation is someone’s-head or flat-out nonexistent, what you’re calling an “AI project” is actually two projects: one to organize the data and another to use it.
The right question isn’t “how much does the project cost?”, but “how much does the project cost, given that my starting point is this?”. Any serious consultancy should be able to look at your starting point and honestly tell you how much of what you’re paying for is building and how much is technical debt (and ideally, what are the hidden costs of not addressing it). If they don’t, it’s because they don’t know or don’t want to say.
2. The Real Scope (Which Isn’t Always the Requested Scope)
“We want a propensity model” can mean very different things depending on who’s saying it (and how data-mature the company is). The range spans from basic spreadsheet calculations, to a notebook with a model trained once, all the way to a production model with continuous training and deployment. It could be two days or six months: the difference isn’t the model, but everything around it.
A significant part of the price depends on how far you go with all the boxes you need to check: ingestion, feature store, CI/CD, monitoring, alerts, retraining, etc. Each of those links is optional on paper, but depending on the case it may be necessary in practice if you want the model to keep working when nobody’s watching.
3. Who’s Actually Doing the Work
There’s a sometimes tacit, sometimes secretive understanding in the industry: seniors sell and juniors build. When it’s time to win the client, companies put their best people forward, but once the contract is signed, the names change and so do the skill levels. The difference with boutique consulting (the category where deployr sits) is that the people who sell are the same ones who shoulder the work. So the rate tends to be higher because there aren’t “multiple tiers of profiles”; there’s continuity throughout the process.
We should clarify that there are projects that probably need the “many junior hands on deck” approach (and honestly, we think it’s very healthy in the medium and long term for less experienced people to gain field experience), but the point is that this should be what your project actually needs (and that you’re paying for what you’re getting).
4. How Much Capacity Stays with Your Team
Every project typically ends with a deliverable. The immediate question is: who receives it, and what do they do with it? Making sure the client organization has the capability to sustain the development takes significant time and effort. Knowledge transfer sessions (which at deployr we even run internally to stay sharp and cross-pollinate experiences) are specifically designed to prevent the saddest reason for development abandonment: that nobody knows what to do with it.
If what is being proposed does not include anyone from your team as an owner in the process, raise an eyebrow: you are buying something actionable today, but with an inevitable dependency down the road.
5. The Length of the Relationship
A three-week project costs differently than a multi-year relationship, and not just because three weeks is “less money”; there’s a whole upfront effort that amortizes differently in a long engagement.
What does that effort involve? Getting deep into the client’s business and understanding the people and processes. All of that, when done right, happens once and amortizes over months or years. In a one-shot engagement, that same cost has to be paid in a few weeks, which is why the effective rate feels higher. It’s no coincidence that our most valuable relationships are also our longest: they’re the ones that allowed us to solve progressively deeper problems on the same accumulated knowledge base.
What You Shouldn’t Be Paying For
Three concrete things to look at when comparing proposals.
Who will you actually be working with? If the consultancy has three layers of management between whoever sold to you and whoever is writing the code, there’s a chain of intermediaries whose time and inefficiency you’re paying for.
Are they giving you a bazooka to kill a mosquito? A responsible consultancy looks to solve a problem, not sell a pre-packaged solution for whatever problem best fits it. Make sure what’s being proposed is tailored to your needs, not to the consultancy’s.
Do the deliverables depend solely on the consultancy? Be wary of firms that say they’ll “take care of everything.” A consultant’s real job is to generate growth, not dependency. If you choose to work with an external organization, it should be to empower you and your team, not to tie you to a third party.
How We Do It
We’re a boutique consultancy that doesn’t sell hours or endless PoCs. We build relationships that start small and grow deep over time. We begin with what we call the First Step: a short, focused engagement of three to four weeks that ends with a concrete deliverable that’s yours, regardless of whether you decide to keep working with us.
For some clients, that deliverable is an honest assessment of where they stand, and they can continue on their own.
For others, it’s the starting point for a technical challenge: a POC or prototype that proves the problem can be solved.
And for others, it’s the first step toward a much bigger change.
We hope this guide gives you something to work with. When you’re ready to start, we’re here to listen.
