If you have been burned buying data services before, the pattern was probably not subtle. Long meetings. Confident language. Expanding scope. Junior delivery teams. Open-ended billing. And at the end, a document, a prototype that never made it into operations, or a system nobody really owned.
The good news is that there are a few clear ways to protect yourself. The safest first engagement is usually narrower than vendors want it to be and more concrete than most proposals make it sound.
Know which type of seller you are dealing with
Broadly, you will run into three types of providers.
- Slides-heavy consultancies. Strong on diagnosis, roadmaps, and transformation language. Often weak on delivering an operational system quickly.
- Platform resellers and implementation shops. Good when the answer is clearly a specific product. Less good when the hard part is cross-system logic, messy source data, or matching records across tools.
- Teams that actually build working decision systems. They start from the business use case, work on real data, and care about the output somebody will use day to day.
None of these are automatically bad. But if what you need is one reliable cross-system output, the third group is usually the right fit. Otherwise you risk paying for slides or licences when the real bottleneck is delivery logic.
Ask what you will actually have at the end
This is the simplest buyer-protection question in the whole process: when the first engagement ends, what exactly will we have?
A good answer sounds concrete. A working prototype on real data. One operational output used by a team. A scoped production plan. Defined maintenance terms. A fixed price and timeline.
A bad answer sounds elastic. Recommendations. Strategic options. A future-phase roadmap. More discovery once the first discovery is complete. If the deliverable is mostly understanding, make sure you truly want to buy understanding. Most teams actually want a working result.
Watch for the discovery treadmill
The dangerous pattern is not discovery itself. It is discovery with no clear exit. One phase becomes another. Scope stays broad on purpose. Every answer creates a new assessment. The client pays to keep learning about the problem without getting closer to a production outcome.
The safer model is a fixed-scope first engagement tied to one use case on real data. Narrow enough to finish. Concrete enough to judge. Useful enough to inform the production build.
That is the logic behind Lucendata’s Mini PoW. It is not an endless consulting track. It is a short, paid engagement designed to prove whether one decision system is worth building and what the next scoped build should be.
Be suspicious of vague teams and open-ended billing
You should know who is doing the work, who is making technical calls, and how the project is priced. If senior people sell the work and juniors you never met deliver it, ask harder questions. If the budget range is wide and the scope is not pinned down, expect the project to keep stretching.
For a first engagement, fixed price and defined deliverables are usually safer than open-ended time billing. You want aligned incentives. Narrow scope. Clear finish line. Real accountability for what gets handed over.
Check the path to production and maintenance
A prototype is not enough unless there is a believable path from proof to production. Ask what it takes to operationalise the output. What needs hardening? Who owns monitoring? What happens when a source schema changes? How are changes requested and supported?
Data systems are living systems. If the vendor cannot explain how the thing will be maintained, you are not buying a solution. You are buying a temporary state.
The safest first data engagement has narrow scope, real data, a working output, fixed deliverables, and a clear maintenance story. Anything fuzzier than that deserves pressure-testing.
The practical buying standard
If you want a clean buying standard, use this one: the first engagement should prove one commercially relevant use case, on real data, within a fixed scope, and leave you with something tangible plus a clear next build. That is a much safer purchase than a broad promise to ‘transform your data estate.’
Mini PoW first. Core build next if the proof is real. Intelligence later if the operation justifies it. That sequence protects the buyer and keeps the work tied to outcomes rather than theatre.