Executive summary
With the advent of generative AI, companies now face a more complicated situation when evaluating a buy vs. build decision. This paper frames this evaluation specifically for solutions (such as AI agents and investigative applications) that rely on multi-source contextual data.
AI coding tools have made application code cheaper to generate. They have not made the data foundation underneath it cheaper to own.
For organizations with fragmented data, complex relationships, evolving requirements, and stringent governance, the real challenge is that foundation: a governed context layer that connects sources, resolves entities, preserves semantic meaning, provides lineage and auditability, and enforces consistent access controls. It increasingly determines the accuracy and trustworthiness of AI agents, and in many data-intensive applications it accounts for the great majority of development effort and long-term ownership cost.
Buy vs. Build in the Age of Generative AI
Own your meaning. AI has made applications cheaper to generate. It has not made the data foundation underneath them cheaper to own.
Get the whitepaperThree strategic choices
The organization assembles, and then owns, the entire stack, including enterprise-scale entity resolution, graph analysis, lineage, security, and schema evolution. This may be appropriate only when no available platform meets the requirements and the system is central to competitive differentiation.
Lower initial risk and faster deployment. But as requirements expand, each new product brings its own data preparation, entity resolution, and governance, adding silos and lifetime cost. Best suited to simple applications with stable requirements.
The ideal solution provides shared data integration, entity resolution, semantic modeling, lineage, access control, and graph, search, and relational analysis on one governed platform, with the freedom to build proprietary applications, scoring logic, and typologies on top. Best suited when time-to-production and cost-containment are important, and when new sources, regulations and use cases are expected: each follow-on application reuses the same foundation.
The economics diverge over time. Even modest schema changes on a custom build trigger significant engineering work; an illustrative calculation in this paper puts the cost at $0.9–1.75 million over five years. DataWalk is such a reusable foundation: the first use case typically runs in production within six months of kick-off. For example, at Ally Financial, DataWalk went from concept to full production in 19 weeks, and Ally now adds new analytical use cases in a single day.
The strategic recommendation
Own your meaning (your typologies, scoring logic and domain knowledge) and buy the foundation underneath.
Direct engineering resources to the applications, business logic, and domain knowledge that differentiate your company, and acquire the underlying capabilities that are complex, expensive, and difficult to maintain at enterprise scale.
Introduction
“With AI coding tools, why not build it ourselves?”
When evaluating a buy vs. build decision for a new application, business leaders now hear this question from their own technology teams, and it deserves a straight answer. Generative AI has changed the economics of writing software: Google says 75% of all new code written there is now AI-generated and approved by engineers, up from 50% in autumn 2025.1 Any buy vs. build analysis written before 2025 is out of date on the cost of producing code. The cost of owning code is a different matter.
Producing code: cheaper
Owning it: not cheaper
The data foundation that sits beneath the application is the code that must stay correct longest and changes most often, so that is where these ownership costs accumulate. For organizations with fragmented data, complex relationships, changing requirements and strict governance, the real choice is whether to build that foundation, buy a point solution for each use case, or buy a reusable foundation and build applications on top of it.
This paper compares the three options on delivery risk, time to production, the effort each following use case requires, and lifetime cost, and closes with the questions to ask before deciding.
1 Sundar Pichai, “Sundar Pichai shares news from Google Cloud Next 2026,” Google blog, 22 April 2026. Vendor self-report.
2 Sawada et al., “To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study,” arXiv:2605.06464 (May 2026), presented at EASE 2026; 1,016 files, 100 repositories, six-month window.
3 Stack Overflow Developer Survey 2026, “Trust in AI tools.”
4 Veracode, “Veracode Finds First Meaningful Gain in AI Code Security Since 2025 as Average Pass Rate Hits 62%,” press release via Business Wire, 29 October 2026.
The hard problem sits underneath the application
Whether the consumer is an autonomous LLM agent or an investigator working a case, it needs reliable context. No one pushes an enterprise database through a prompt; no context window holds billions of records. So an agent working over fragmented, poorly connected data has to generate ad-hoc code and queries on the fly to find, join and reconcile what it needs. Every answer then rests on unreviewed code, run against entities that were never resolved: results vary from run to run, are hard to audit, and cost more to produce. A case management system without consistent entity resolution turns into another silo and sends analysts back to reconciling records by hand.
What's needed is a governed context foundation that provides connected sources, resolved entities, semantic meaning, lineage, auditability, inference, graph and relational performance at scale, and access control applied consistently to users, applications and AI agents.
Figure 1. One context foundation serving multiple agents and applications
Industry analysts now say this directly. In May 2026 Gartner predicted that by 2027, organizations that prioritize semantics in AI-ready data will increase their agentic AI accuracy by up to 80% and reduce costs by up to 60%.5
“Context with semantic coherence will become a cost-control and trust strategy, not a nice-to-have.”
Rita Sallam · Distinguished VP Analyst, Gartner5
The 40% figure is a prediction, not an observed failure rate, and Gartner does not attribute it to data quality specifically. We cite it for the cost and risk-control half of the argument.
5 Gartner, “Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending,” press release, 11 May 2026.
6 Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” press release, 25 June 2025.
Where the effort goes Most of it is hidden
Development effort and total cost of ownership are most often underestimated in the context layer. The expensive part is not the first application. It is building the foundation, then reworking it each time a regulation, data source, use case or application changes.
Based on DataWalk’s experience building a context foundation and applications on it, we estimate the context layer accounts for most of the work in a new data-intensive application, in the order of 90% (Figure 2).7
Figure 2. The custom development iceberg: most of the effort is below the waterline7
10%
End-user application
What users and AI agents see
90%
Context resolution foundation
What has to be built, then owned for the life of the system
- Ontology and knowledge graph
- Multi-source ingestion and fusion
- Entity resolution
- Permissions
- Performance and scalability
- Search, graph, and relational computation
- Data lineage and audit trail
Ideally an organization builds one context foundation and shares it across applications. With that in mind, here are three ways to deliver a new application.
7 DataWalk estimate based on its experience building a context foundation and applications on it. Not an independent study.
Option 1 Build from scratch
Today, building from scratch rarely means writing applications from zero. Teams assemble a stack from commercial parts: a developer graph database, a data fabric, a virtual semantic layer, and an entity resolution library. On paper this looks lower risk. In practice the risk moves into the integration code between the parts. The organization becomes its own systems integrator, maintaining pipelines, chasing query latency across federated layers and reworking the schema every time a source changes. You aren’t buying a solution; you are taking on a long-term commitment of keeping a set of disparate components from breaking.
Even with smart people, modern AI tools, and robust components, developing a context resolution foundation is a significant, long, high-risk project. It may include development and long-term ownership of entity resolution at scale (billions of records); the fuzzy matching and weighting engine behind it; auto-connect; the inference layer; the scoring framework; graph algorithm implementations; the investigator workflow and case management; the NLP and entity extraction pipeline; the normalization apps; Machine Learning feature generation; and the graph model maintenance process that has to run every time a schema change forces a rebuild.
AI coding tools speed up individual components and make interfaces quick to generate. The evidence from 2026 says they shift effort rather than remove it:
Veracode’s October 2026 update found the average security pass rate rose from 56% to 62%, with the best models at 73%. Roughly four in ten tasks still produce code that fails security testing.4
A May 2026 study of agent-generated files in 100 GitHub repositories found that human developers still made 83% of subsequent changes to files the agents had created: maintenance continues to rest with people.2
In the Stack Overflow 2026 Developer Survey, 48% of developers trust AI output when they can easily verify it, and 6.6% trust it for important work decisions.3
Gartner predicts that by 2028 AI coding costs will exceed the average developer’s salary, driven by token consumption and consumption-based pricing.8
METR’s randomized study found AI made experienced open-source developers 19% slower in early 2025. Its early-2026 follow-up believes developers are now likely faster, but describes its own data as only very weak evidence of the size of the gain.9
2 Sawada et al., “To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study,” arXiv:2605.06464 (May 2026), presented at EASE 2026; 1,016 files, 100 repositories, six-month window.
3 Stack Overflow Developer Survey 2026, “Trust in AI tools.”
4 Veracode, “Veracode Finds First Meaningful Gain in AI Code Security Since 2025 as Average Pass Rate Hits 62%,” press release via Business Wire, 29 October 2026.
8 Gartner, “Gartner Predicts AI Coding Costs Will Surpass Average Developer’s Salary by 2028 as Token Consumption Surges,” press release, 24 June 2026.
9 METR, “Measuring AI uplift: an update,” 24 February 2026; original study arXiv:2507.09089 (July 2025).
Option 1 Ownership and the cost of change
An agent can generate business logic in days. AI tools do not, however, eliminate the need to architect, integrate, validate, secure, and continuously maintain a production-grade context resolution foundation. The challenge is not simply generating code; it is ensuring that the complete system performs reliably as data, schemas, workloads, and business requirements evolve. The governed foundation underneath (lineage, entity resolution at volume, concurrency, access control, schema evolution) remains the long-running and risky part, because it has to stay correct for as long as the applications depend on it.
DataWalk has invested several hundred engineering-years in developing its adaptable foundation. DataWalk developed unique technology for this (10+ patents), and few IT organizations have such capability.
The cost of change
Five-year TCO models usually assume the system deployed in year one is the system running in year five. In anti-fraud, AML and intelligence that is false: typologies, regulations and data sources change continuously. On a self-assembled stack, a schema change typically means rewriting ingestion, refactoring the graph model, and in some cases reloading data. It is critical to specifically consider this “cost of change” (technically, the “schema evolution penalty”). On DataWalk, model changes are done via configuration and do not require that pipelines be re-engineered.
An illustrative calculation, using our own assumptions:10
| Assumption | Value |
|---|---|
| Engineer-days per schema change on a custom build | 20–35 |
| Cost per engineer-day | $900–1,000 |
| Cost per change | $18,000–35,000 |
| Changes per year | 10 |
| Unbudgeted cost over five years | $0.9–1.75M |
Figure 3. The cost of change on a custom build: an illustrative calculation10
AI coding tools will likely lower the engineer-days per change. They do not remove the review, testing, data migration and re-validation of entity resolution that follow each change.
When building makes sense
Building may be the right choice when (a) no available foundation, DataWalk included, meets your requirements, and (b) the system is central to your competitive differentiation. Outside those conditions, the timeline, cost and extensibility risk of building everything is hard to justify.
10 DataWalk illustrative calculation: 20–35 engineer-days per schema change at $900–1,000 per engineer-day; ten changes per year for five years. Assumptions, not measured data.
Option 2 Buy a point solution
A point solution for a defined set of use cases carries far less delivery risk than custom development, deploys faster and may cost little up front.
The trouble starts when requirements change. A new regulation, use case or application may mean changing the schema, or buying another point solution with its own context engine. The result is a collection of tools that each prepare data, resolve entities and define terms in their own way, with duplicated integration work and fragmented governance. This is work that many organizations are specifically trying to reduce.
A point solution can be the right choice when
- 01The application is simple
- 02Requirements are unlikely to change much
- 03Adding another point solution to the estate is acceptable
- 04Long-term cost is not a primary concern
Figure 4. Each point solution brings its own context engine
Option 3 Buy a context foundation and extend it
Buying a context resolution foundation such as DataWalk combines the reduced delivery risk of packaged software with the flexibility to seamlessly add new data sources, requirements and use cases. Investigation and analysis functions are built in.
DataWalk provides in one platform: multi-source data integration, entity resolution, semantic modeling, lineage and auditability, granular access control, and graph, search and relational analysis at scale. Applications and AI agents reuse this governed foundation instead of assembling the same capabilities for each use case.
DataWalk is also extensible. You can build custom applications on it with the DataWalk App Center, which runs scripts, open-source tools and models inside the platform against DataWalk data,11 and you can embed DataWalk functions in existing systems and agents.
Buying a foundation does not stop you from innovating internally, and instead enables you to put more focus on these key innovations. You are buying the parts that are hardest to build (graph engine, entity resolution, lineage, concurrency) and keeping your typologies, scoring logic and domain knowledge as your own.
The common objection with this class of vendor software is lock-in: becoming permanently dependent on vendor forward-deployed engineers to keep the system running. DataWalk is different. DataWalk’s delivery model is customer-led. Our engineers train your team to own, change and extend the schema and the applications themselves.
Figure 5. Typical results. The first use case builds the foundation; the next ones reuse it
The first use case on DataWalk, including the context foundation, is typically up and running in production within six months of project kick-off, a timeline that can be included in the SLA.12 For example, at Ally Financial, DataWalk went from concept to full production in 19 weeks. Ally now deploys new analytical use cases in a single day, and can add use cases for additional functions without additional technology investment.13
“DataWalk allowed us to bring all of our data together in one place, standardize it for the first time, and finally run true cross-business-line analysis. Before that, we were completely siloed.”
Brian La Rose · Senior Director of Technology, Ally13
11 DataWalk, “App Center,” datawalk.com/product/app-center.
12 DataWalk delivery experience; measured from project kick-off. This timeline can be included as an element of the SLA.
13 DataWalk, “Always Ahead: Building the Safest Digital Bank in America,” Ally Financial customer success story, April 2026, pp. 3, 5, 7.
Comparing the three options
Figure 6 provides a summary comparison of the three options.
| 1 · Build from scratch | 2 · Buy a point solution | 3 · Buy a context foundation | |
|---|---|---|---|
| Delivery risk | High | Low | Low |
| Time to production | Slow | Faster | Fast |
| Effort for following use cases | High | High (often a new product) | Low |
| Lifetime cost | High | High as point solutions multiply | Lower |
| Code generation cost (2026) | Falling fast | n/a | Falling (apps on top) |
Figure 6. Comparison of alternative strategies
A practical path forward
For most organizations, building their own context foundation or accumulating point products costs more and carries more risk than the alternative, both now and over the system’s life. Cheaper code generation narrows the gap for the application layer. It does not narrow it for the foundation, where the 2026 evidence on quality, security and maintenance points the other way.
A context resolution foundation lets you keep your engineering effort on what differentiates your company, instead of repeatedly building and maintaining the same underlying capabilities.
When each option fits
When no available foundation meets your needs and the system is central to strategic differentiation.
When the application is simple, requirements are stable, and point-solution sprawl and long-term cost are not concerns.
When new sources, requirements, and use cases are expected, so each follow-on application reuses the same foundation.
Questions to ask before building a custom solution
If you are considering development of a custom solution, ask the following questions. Some are for the business to answer; others are for the engineering team that proposes to build it.
For the business sponsor
Questions to answer before approving a build
- 01Is this software a key driver of your core competitive advantage?
- 02Is there an existing product that meets your needs for a context foundation or the application?
- 03Do you have an objective to reduce the number of point products?
- 04Will you staff this as a permanent product team rather than a project?
- 05What track record says your organization can deliver this class of software on time, on budget and to requirements?
- 06If you could build a context platform that meets the requirements for concurrency and adaptability (i.e., schema evolution), are you confident it would not infringe on existing patents?
For the team proposing to build it
Questions to ask the engineering team
- 01If you build it, will you rebuild or duplicate the context foundation for the next use case?
- 02If you believe you can build a reusable foundation, what evidence says your schema can evolve without re-engineering?
- 03Without a shared, governed foundation, will each new application add another silo and more technical debt?
- 04If the team plans to generate this with AI coding tools, how will it validate lineage, scalability, security and multi-source entity resolution at production volume? Who reviews the output, and what is the token budget?
- 05How will thousands of users, workflows, queries, scoring rules, permissions and AI requests run concurrently over the same governed context, without duplicating data, breaking lineage, losing security controls or producing inconsistent answers?
- 06Will the solution you plan to build be able to analyze complex relationships across hundreds of millions to billions of records and relationships, without continuous engineering effort to tune and optimize performance?
About DataWalk
DataWalk is a data and analytics platform with an enterprise knowledge graph that supports graph, search, and relational analysis over shared underlying data. Organizations use it as a context resolution foundation for investigations, analytics, and AI agents, with source lineage, auditability, and granular access controls.
Buy vs. Build in the Age of Generative AI
Own your meaning. AI has made applications cheaper to generate. It has not made the data foundation underneath them cheaper to own.
Get the whitepaperDataWalk Platform
See DataWalk in action
Request a personalised live demo and discover how DataWalk connects the dots across your data.
