Most AI projects stall on the data, not the model. We find out whether yours can support what you want to build, reconcile the sources that disagree, fill or work around the gaps in the history, and put monitoring in place so it does not drift once you are live. Done by the senior engineers who then build on top of it, for companies of any size.
Tell us where you are, modernising a legacy warehouse, scoping AI-ready data products, or rebuilding governance after a re-org, and we'll tailor the engagement. Typically four to eight weeks from first call to roadmap readout.
Most AI projects stall on the data rather than the model, and they stall in three recognisable ways: the sources disagree with each other, the history needed to train on is incomplete, or the pipeline drifts once the model is live and nobody notices for a quarter. Data strategy consulting is the work of finding out which of those you have and fixing it. Winder.AI has done all three in production: a global airline's taxi-time prediction had to be built from multiple disparate source systems with incomplete records, its flight-scheduling work had so little operational data that we built digital twins to generate it, and Apartment List's machine learning platform was rebuilt around a Chalk feature store that removed the data drift breaking their models. We prepare the data, then build on it, rather than handing the problem to someone else.
2026 update. The question has shifted from "do we have a warehouse" to "can our data answer the question we are about to ask a model". Generative AI exposes every weak seam in lineage, access control and data quality, and retrieval augmented generation fails quietly when the underlying documents are stale or duplicated. Our 2026 work covers retrieval quality and the data behind it, feature stores and drift monitoring for models already in production, and the EU AI Act and ISO/IEC 42001 implications of using your own data to train and ground a system.
Data strategy vs data science. This page is about getting the data into a state a model can use. If your data is already in good order and you need a delivery partner for predictive models, forecasting, anomaly detection or production ML, start with our [data science consulting and development service](/services/data-science-consulting/index.md). Many clients do the data work first, then move into delivery with the same engineers.
| Strategy approach | What you get | Best for | Main weakness |
|---|---|---|---|
| Big-4 / global SI data strategy programme | Branded data strategy framework, executive workshops, target operating model decks and a multi-year transformation plan | Board-level signalling, multi-year change programmes, regulator-facing narrative | High six-figure cost, slide-deep but engineering-shallow, junior analysts behind a senior pitch, recommendations rarely survive contact with the actual platform team |
| In-house build (CDO-led, no external partner) | Strategy owned inside the data function, integrated with existing teams and politics | Mature data orgs with a strong CDO, senior architects and slack capacity to step out of delivery | Hard to be honest about own platform; slow to triangulate vendor claims; rarely benchmarks against modern reference architectures; competing day-to-day priorities |
| Boutique data strategy consultancy (analyst-led) | Polished discovery, target-state diagrams and a 12-month roadmap built from interviews and reference frameworks | Organisations that need a credible written strategy and have a strong internal engineering team to deliver it | Light on engineering depth, no hands-on production experience, the roadmap often glosses over the hard platform and AI delivery details |
| Vendor-led "strategy" (warehouse, lakehouse or cloud sponsor) | Free or subsidised strategy work that frames your future around the sponsoring vendor's stack | Confirming a vendor choice you have already made | Conflict of interest; understates lock-in, switching cost and feature gaps; rarely covers governance, operating model or AI-readiness honestly |
| Data readiness for AI (Winder.AI) | A written read on what your data can and cannot support, the specific gaps blocking it, and the pipeline and monitoring work to close them. Written by the engineers who did the same work for a global airline and for Apartment List, and who can carry on into the build. | Teams with an AI project blocked on the data, who want the blockage named and cleared by the same engineers who will build on top of it | We do not do target operating models, RACI matrices or multi-year transformation programmes; if you need a board-facing change narrative, the Big-4 row is the honest answer |
Winder.AI runs this as one connected engagement: establish what the data can support, fix the pipeline that feeds the model, and keep it correct once it is live. One engineering team throughout, and no handover between the people who wrote the recommendation and the people who have to build it.
We sought AI engineering experts that could quickly learn our day-to-day scientific legal mapping processes enough to develop a tool to make our work more efficient. Winder.AI dug into our day-to-day workflow to thoroughly understand the value of an AI Assistant for scientific legal mapping, which is a critical process to the field of legal epidemiology.
Senior AI engineers doing the data work that production systems actually need, with vendor-honest platform recommendations and no reseller agreement behind them.
Data readiness, pipelines and production AI across aviation, property technology, legal research, finance and healthcare.
Each area below is a scoped workstream with named owners and a written artefact at the end. Most engagements need three or four of them, not all seven:
The specific capabilities we bring to the data layer underneath an AI system. Each is in scope on a typical engagement:
Case study
Winder.AI helped Duetto evaluate offline reinforcement learning for dynamic hotel pricing. Over five months, the engagement progressed from behavioural cloning baselines through Implicit Q-Learning experiments on real booking data, revealing where RL outperforms simpler approaches, what data quality prerequisites exist, and how to evaluate pricing agents when ground truth is unavailable.
Case study
Winder.AI helped Apartment List modernize its machine learning operations by unifying data pipelines, automating Kubeflow workflows, and introducing enterprise-grade governance. The outcome: consistent training and inference data, faster deployment cycles, and self-service capabilities that enabled Apartment List’s data science team to scale model delivery with confidence.
Case study
Using digital twin data to build flight traffic simulators and train reinforcement learning AI agents. A leading aerospace business and Winder.AI opened new horizons for dynamic, data-driven scheduling solutions that integrate with our client’s advanced flight planning technology.
AI Agents
I’ve spent the last few months on Helix-Org, my attempt at rebuilding an organisation as AI agents. The first version had me writing hyper-specific agents in code, each one specialising in a single job. It worked, and it became tiresome: every new job meant another small program to write, test and maintain. Eventually I tried describing one of them in Markdown instead and handing it to a harness. It did the same job. Markdown is now code.
DeepSeek shipped an agent harness in developer preview on 13 August 2026, and it collected 95,386 GitHub stars in about two days, one of the fastest adoption curves GitHub has recorded. The thing I stumbled into has a name, a plugin standard and nine products worth choosing between. We run seven of them. Which one you pick matters less than which layer you need, and no feature grid answers that.
AI
We spent five months with Duetto working out whether reinforcement learning could price hotel rooms better than the heuristics they already had. The algorithm was never the hard part. Nobody can observe what demand would have been at a price the hotel did not charge, so there was nothing to check an answer against, and the measuring instrument had to be built before anything we said about the agent meant much. When we turned on that instrument and looked at it properly, the revenue lift it reported correlated with the error in the demand model underneath it. It had been flattering the agent in proportion to how wrong it was.
Agents built on language models have a smaller version of the same problem, and it arrives the week someone senior asks whether the thing is safe to ship. Until the measuring instrument exists, everything the agent produces is an anecdote.
AI
The agent has been fine for six weeks. Then a customer complains, you open the trace, and every step is green. Nothing timed out, nothing threw an exception, and the summary at the end says the job is done. It is not done.
Agents fail in production in a small number of recognisable ways, and almost none of them are the model being wrong. They call the right tool with the wrong arguments. They run out of context partway through a long task and forget a constraint you gave them at the start. They report success after a step that failed. They loop, and you find out when the bill arrives. Or they answer confidently from data that stopped updating on Tuesday.
Every one of those has an engineering fix, and every fix is code inside your agent loop, not a product you buy.
This page provides answers to our most common questions. If you have a query that isn't covered, please get in touch.
Whether your sources disagree, your history has holes, or a model that worked last quarter has quietly drifted, talk to the engineers who have been preparing data for production AI since 2013.
Send us a brief and book a welcome call within 48 hours.
Talk to the data strategy team