What does building a document parser actually cost?
A developer building a parser on top of an open-source toolkit or cloud API (Google Document AI, AWS Textract, Azure AI Document Intelligence) can have something working within a few weeks. The problem is not that first version, but everything that follows. Document formats are not stable: suppliers update their PDF layouts, a new customer sends a poor-quality scan, a bill of lading suddenly includes an extra line block. Every variation requires adjustments to the extraction rules. Without a team to handle those adjustments, accuracy degrades slowly but steadily. That maintenance is structural, not a one-time effort, and it is rarely factored into most business cases.
Subscription costs versus build costs: how does the comparison stack up?
A managed solution charges per document or per month. That feels like an ongoing cost, while building sounds like a one-time investment. But the calculation shifts quickly when you are honest about the full cost of building: initial development work, integration with your ERP or TMS, testing edge cases, and then ongoing maintenance for every document variation. With managed solutions like dottle, integrations with systems such as Exact, AFAS, SAP, or Dynamics are pre-built, scalability is handled, and time-to-value is typically two weeks rather than months. That difference in time also carries a price: every month your team is still manually retyping data is capacity that is unavailable elsewhere.
Document variations are the biggest maintenance problem
This is where most in-house build projects fall apart. A parser that works well on twenty known formats from twenty fixed suppliers starts to break down the moment a format appears that is structured slightly differently. Rule-based extraction is inherently fragile when layouts vary: you can keep extending the rules, but the pile of exceptions grows along with them. Managed solutions do not solve this by magic, but they place the maintenance responsibility with the provider, not with your IT department. New formats are added in a controlled way without requiring you to schedule a sprint for it.
When does building in-house make more sense?
There are situations where custom development is the more logical choice. First: when you face strict data-residency requirements or air-gapped environments where documents cannot leave your own infrastructure. Second: when your document formats are so unique and stable that a generic approach consistently falls short. Third: when your volume is high enough and document structure predictable enough that the management costs of a custom solution are lower over time than a per-document rate. In practice, that last scenario is only realistic at very high volumes with a dedicated technical team actively maintaining the parser. For most operational teams in transport, food, or wholesale distribution, that does not apply: their IT department has other priorities and document formats vary more than expected.
What are the honest limitations of a managed solution?
A managed document parser is not a silver bullet. If your source documents are structurally poor quality (blurry, handwritten, inconsistent), no system will handle them fully. If your process is not well-defined, meaning it is unclear which data you need and for what purpose, then automation is premature regardless of the tool. And if your volume is low (a few dozen documents per month), the investment will not pay off. dottle is straightforward about that boundary: when volume is too low or a process is not yet mature, we advise waiting. The value lies in repetitive, predictable, high-volume document work.
Conclusion: make-or-buy for document parsing
For most operational teams, building your own document parser costs more than it appears and delivers less than expected. The build costs are visible, but the maintenance burden, the delay in time-to-value, and the internal capacity tied up in the effort are far less so. A managed solution like dottle is live within two weeks, connects to the systems you already use, and keeps the responsibility for handling format variations with the provider. Custom development is the better choice when there are specific privacy requirements, stable unique formats, or extremely high volumes supported by a technical team that can sustain it structurally. In all other cases, it is a more costly path than necessary.