Build vs. Buy for AI Agents: Why In-House Development So Often Gets Stuck
One sentence keeps coming up more and more often in our first conversations with mid-sized manufacturing and trading companies: "We already tried to build this ourselves." An IT service provider tasked with developing a custom AI agent for order entry ultimately recommended approaching a specialized provider instead. The management of a manufacturing company had spent months trying to set up an AI solution on top of their own ERP system, without a reliable result. And a consulting firm that works with several hundred mid-sized companies had already built a custom OCR tool for one client, but wasn't sure whether that was the right path for its other clients.
Three different starting points, one common pattern: building an AI solution for document processing in-house sounds straightforward, especially because modern AI tools seem so easily accessible today. In practice, though, many of these projects get stuck at a similar stage.
Key takeaways
- More and more mid-sized companies are experimenting with their own AI solutions for order entry and document processing.
- In practice, many of these projects don't fail because of the AI itself, but because of missing unambiguous reference data, ongoing maintenance effort, and a lack of training material.
- At the same time, larger ERP vendors are starting to build initial AI-based document recognition features directly into their systems, a trend companies should keep an eye on when making their build-or-buy decision.
- A structured checklist helps make the build-or-buy decision based on facts rather than gut feeling.
Why in-house document AI projects often stall
At first glance, the task looks manageable: a language model, a handful of sample documents, done. In practice, three recurring hurdles tend to show up.
The hidden costs of building it yourself
What's usually missing from the first calculation:
- Training data and ongoing model training: A model trained once on ten sample documents stalls on new document types, layouts, or edge cases unless someone keeps refining it continuously.
- Compliance responsibility: Anyone deploying or connecting their own language model also takes on responsibility for data protection and compliance evidence, an effort that specialized providers already deliver solved.
- Opportunity cost: Every hour that IT or automation teams spend building an order assistant in-house is an hour missing elsewhere.
💡 Pro tip: Before starting an internal project, calculate not just the development time, but also the ongoing maintenance for the next three years. Most in-house projects we know of failed in year two, not month one.
The new factor: ERP vendors are catching up
Alongside individual companies' in-house attempts, we're seeing a second trend: larger ERP vendors are starting to build initial AI-based document recognition features directly into their systems. For companies currently weighing in-house development, native ERP functionality, and a specialized provider, three questions are worth asking: Does the native feature cover only a single ERP system, or also other channels such as email inboxes and multiple connected systems? How long has the solution already been in productive use with other customers, and how many different document layouts has it been trained on? And: who takes over maintenance when a document format changes?
A checklist for the build-or-buy decision
- Do we have unambiguous reference data in our systems (customer numbers, a central case ID) that lets a document be assigned without doubt?
- Do we have the internal capacity to maintain an AI model long-term and retrain it for new document types, not just develop it once?
- How many different ERP systems or inbound channels (email, portals, EDI) would a solution need to cover?
- Who takes responsibility for data protection and compliance evidence in an in-house build?
- How much time until first productive use is realistic, and what does each month of delay cost in manual work?
Frequently asked questions (FAQs)
Can I build an AI agent for order entry myself?
Technically, yes, with today's language models a first prototype can be set up comparatively quickly. The real challenge isn't the first prototype, but ongoing productive operation: edge cases, format changes, and continuous training that require sustained capacity.
What's the difference between a native ERP AI feature and a specialized provider?
A native ERP feature is usually tailored to a single system and typically doesn't cover all inbound channels (email, portals, different document formats). Specialized providers, on the other hand, often work across systems and already bring experience from many different industries and document types.
How long does rolling out a specialized solution take compared to building it in-house?
An in-house prototype can show first results quickly, but the path to a stable production environment often takes longer than planned. Specialized providers with already-trained models typically reach productive operation within a few weeks to around two months in practice.
Is building it yourself ever worth it?
Not as a general rule. For very specific, low-complexity cases, a simple internal script can be enough. But once multiple document types, edge cases, and ongoing maintenance come into play, experience shows that the running costs of an in-house build are regularly underestimated.
Conclusion
Building an AI solution for order processing in-house rarely fails on basic feasibility, it fails in year two, once maintenance, edge cases, and new document formats pile up. Companies that work through the build-or-buy question based on their own data situation, capacity, and time costs, rather than gut feeling, end up making the more solid decision.
Keep reading: Here's how automated order entry works with Workist.
