The question every serious operator asks

In “No Shortcuts,” the companion to this piece, we outlined that AI in repair management only delivers once the foundations underneath it are built, and built in the right order: unified data, an intelligence layer, decision capture, prescription, and only then automation and agentic AI services.

Many leaders are coming under increasing pressure to form and execute an AI strategy. For those keeping an eye on the news, there is seemingly no end to the hype around AI and its capability to “eat software,” calling into question the long-standing truism that non-software companies should not build their own software.

In the wake of this sudden and accelerating paradigm shift, there is an obvious and justified question: “Why don’t we just build it ourselves?”

It is the right instinct. Owning core capability is usually good discipline, and automation in the manual paper-led processes of repair management certainly feels core.

We take the question seriously, because the executives asking have usually thought harder about it than the average vendor gives them credit for.

What building AI solutions for repair management looks like

Let’s assume you can get to work today, without the months or years of strategic planning.

Where to begin? Hire a data and machine learning team. Buy in an enterprise data platform. Bring in a consultancy for the domain and integration work. Build.

A serious attempt needs a sustained team of data engineers, analytics engineers, data scientists, software engineers, product designers and subject matter experts. Still, the scaling constraint is not the ongoing salary budget.

It is finding people who understand, or can learn quickly, both heavy-industry repair and modern technology engineering: these people barely exist. The expertise that lives in people who came up through repair shops, or those in established high-performing data teams, are almost never in the same person. Even finding them separately is a huge challenge.

Finding, combining and retaining that rare mix is the critical difficulty, and it does not get easier at scale. Furthermore, these skillsets are in incredibly high demand in today’s market. There is far more demand than supply, so they will not come cheaply.

Now, let’s assume you somehow assemble this team. When can you finish building? In a world of such rapid technological acceleration, you are never really “finished” with AI solutions. Data, software and AI require continued iteration and adoption of the latest technologies to remain a competitive advantage. It’s not a “one-off build and then maintain” commitment. The building either never stops, or gets outdated.

A bespoke repair intelligence platform assembled by a large consultancy is a multi-year, multi-million-dollar program, and at the end of it you own a system they understand, staffed by people who leave when the contract ends or are extremely costly to retain. The enterprise data platform underneath is a seven-figure annual commitment at scale. And then there is the quietest cost of all: time. Three to five years to something genuinely useful, if the solution survives contact with reality.

A serious in-house attempt is a seven-to-eight-figure, multi-year commitment, with a high probability of plateauing. And the most uncomfortable part? Even if you spend all of that money and time and find success, two barriers remain standing, because having a capability and producing an outcome are not the same thing.

Barrier one: the data does not exist

You cannot point an AI solution at your existing systems and get automated repair management outputs, because critical data is not in your systems in usable form. It sits in supplier quotes and teardown reports saved as PDFs and Excel documents. It sits in email negotiations, in inconsistent ERP exports, and in the judgment and wisdom of a handful of long-serving experts.

Before AI can use it, it has to be created: extracted, reconstructed and structured, document by document, expert by expert, through years of unglamorous work. This is an unwanted additional cost to the P&L driving costs and timelines, away from the actual business of developing the platform.

In our experience, the document ingestion providers in the market cannot extract data from these documents with the fidelity and accuracy required, which is why we have spent more than six years building our own Document Intelligence solution for exactly this kind of work.

It is impossible to overstate how critical a factor document data quality is in AI use cases for repair management. Many “intelligent document processing” providers only focus on processing a handful of simple key fields, and beyond that (for critical data like tables of piece parts) offer ~80% accuracy. This leaves system operators to allocate administration resources to manually check the data, adding cost, slowing process and carrying its own human error rate.

Beyond the document ingestion, there is also the process of onboarding existing datasets from ERPs and other systems. These legacy systems are often full of incomplete or incorrect datasets, human errors, and inconsistencies.

It only takes a handful of interactions with an AI solution that gets it wrong before users lose trust, and whether it gets it right is almost entirely determined by the quality and structure of the underlying data and the ontology/semantics that enables it to be properly understood.

There is a quick test for whether any partner, internal or external, understands this. Ask who owns the data quality after the onboarding process. Teams that onboard data without validating it, enriching it or taking ownership of it will give you a service-desk answer: “bad data in, bad data out”, or something less polite. Teams that own quality from onboarding through to outcomes will tell you exactly how data quality issues threaten your shared goals and will want to work through the problems one by one. The difference between those two answers is the difference between buying a data platform that is repackaging what you already have, and partnering to produce quality outputs.

Barrier two: the organization isn’t designed for software development

This one has to be said with respect, because it is not a criticism. A large operator in a safety-regulated domain is, correctly, built for reliability, compliance and process discipline. Those are exactly the right properties for running an airline. They are the wrong properties for building and continuously iterating on an AI-native software and data product, which needs speed, tolerance for throwaway work, tight loops between design and engineering, and a culture that treats the software as never finished.

This is a mismatch of organizational shape and culture. A large, regulated organization building software tends to build it the way large, regulated organizations do everything: through committees, through contractors, slowly. The product that emerges carries the fingerprints of the process that made it.

The partner the problem actually needs

So, who should build it? Not the operator in many instances, for the reasons above. And, in our view, not a giant horizontal software vendor either, because this problem punishes anyone who cannot understand the level of detail and variation repair management holds. As just one example, the component quote analysis engine in the ValStream Platform covers more than 20 diagnostics across warranty, contractual, tactical and engineering checks, with tens of thousands of potential outcomes for each and every quote.

The builder this problem needs is established enough to be credible at scale, but small enough to still ship at the speed AI-native product work demands. Established enough to play at the level of major aviation businesses, but not so large as to have lost agility.

Delivering AI solutions in repair management takes three things in rare combination.

  • Data expertise: building real operational data, enriched and structured into a standardized model from the actual raw inputs, reconstructed from documents, ERP exports, market data, industry master data and supplier correspondence. If you cannot fix the data, you are repackaging the problem.
  • Technology expertise: proven ability to develop workflow and decision technology, with genuinely excellent user experience, sitting inside the flow where decisions are made, saving time rather than adding work, empowering better decisions, and capturing new data simply by being used. Not to mention the expertise required to enable the deployment of the bleeding edge in AI capabilities.
  • Domain expertise: held inside the company and fed back into the product by people who understand repair deeply, from hundreds of collective years in the industry across process, compliance and engineering, and who care about getting it right, after years of wondering about how much better it all could be.

Any one of the three is findable on the market on its own; the combination is not. At ValStream, we have spent years assembling it quietly, customer by customer, workflow by workflow, across components, engines, heavy/base maintenance, line maintenance and inventory in aviation.

At this point it is worth being clear about what ValStream is not, because the category is crowded with things that look similar from a distance. We are not:

  • a model wrapper on top of data you already have
  • another IT system
  • traditional consultants

We never replace your ERP or E&M systems; we sit to the side of them, creating intelligence around the systems that carry your compliance.

We innovate with your people rather than around them: your experts stay in the loop, with better tools for improved decision quality than they have ever had.

Underneath all of it sits the measure we hold ourselves to, because it is the one the software industry continues to struggle with. Much of the AI now being sold makes people somewhat more productive, but once the licenses and tokens are counted, it costs more than it returns. Our focus is the opposite: fiscal cost savings come first, measured in the customer P&L.

Based on results achieved with existing customers, we are highly confident in delivering a return of several times the investment in direct fiscal value. Furthermore, because our platform tracks identified and realized dollar value automatically, in a form your finance team can report on, the value generated is material and verifiable rather than theoretical.

An in-house build, by contrast, is a cost center for years before it saves a dollar. A partnership is judged on savings from the first engagement.

Save money today, future-proof tomorrow. That is the mission.

Where building might be the right choice

An argument is only as credible as its treatment of the other side, so here is the case for building.

The very largest players with existing software heritage, maintenance software, a repair network, or a warranty and claims book, have a higher probability of success following an in-house path. They start with assets that an ordinary operator lacks, and for them a “build rather than buy” case deserves genuine analysis rather than dismissal. Even they, though, run into a prominent barrier. A platform owned by a company that is also a competitor or a service provider in the market is structurally compromised as a neutral intelligence layer. Independence is a hard requirement for any provider in this area.

In conclusion, for a pure operator, without a software and data heritage, there is a lower probability of an in-house path to this capability being successful. The cost of failure goes far beyond the money spent. Time, distraction and operational strain on the teams trying to make it succeed all add up, and while they do, dedicated software providers keep moving their capabilities forward. The operator that chose to build ends up further behind than when it started.

A small first step to inform a large decision

The good news is that the build-or-buy decision can be tested quickly without a long-term commitment. With ValStream, testing your internal hypothesis takes weeks:

  • Sign the appropriate data-sharing agreements.
  • Share your dark data: quotes, invoices, teardown reports, ERP exports, anything with value locked inside it.

We will come back with a picture of your historical spend and trends at a granularity you have not seen before, and a proposal for turning that insight into working systems. Your data remains your own, protected to the highest standards.

The discovery, the first insights and the first cost-saving opportunities take weeks, not quarters. The platform will pay for itself very quickly. The process will tell you more about us as a partner than an RFP ever could.

What this platform becomes over the next few years, for the operators who take that step, is a story of its own. We have outlined this in the final piece in this series: “Our Vision: Automation to Intelligence in Repair Management.”