DEV Community: DEVALAND

AI Automation for Multi-Entity Founders

DEVALAND — Mon, 10 Aug 2026 14:00:06 +0000

If you own several companies under one roof, the fastest AI win is not a flashy chatbot. It is automating the same manual document and data work you already repeat across every entity. Start with one high-volume workflow, prove it in a two-week pilot, then reuse the same engine across the group.

Most advice about AI automation is written for a single business. That advice quietly misses the biggest advantage a multi-entity founder actually has. When you run a holding company, a roll-up, or a group of related businesses, your pain is not one broken process. It is one broken process copied five or ten times, once per entity, each handled a little differently. That repetition is a cost when done by hand. It is a gift when you automate, because you build the solution once and it pays back everywhere.

Why Owning Multiple Companies Changes the Math

A single company automating an invoice workflow saves one team some hours. A group of eight companies automating the same workflow saves eight teams those hours, from one build. The engineering effort barely changes. The return multiplies by the number of entities.

This is the part owners underestimate. You are not looking at eight separate automation projects with eight budgets. You are looking at one project that happens to run in eight places. The economics of custom AI, which can feel expensive for a single small business, become very comfortable when the same system serves a whole group.

There is a second, quieter advantage. Because your entities are related, they share document types, vocabulary, suppliers, and reporting rhythms. A workflow tuned for one of them usually needs only light adjustment for the next. You are compounding, not restarting.

The Highest-ROI First Targets

Across groups I have worked with, the same four candidates keep rising to the top. They are boring, repetitive, and expensive precisely because a human does them today.

Workflow	What it looks like now	What AI changes
Document intake	Someone opens PDFs, reads them, retypes fields into a system	Extract fields automatically, flag anything uncertain for review
Cross-entity reporting	Each company sends numbers in its own format, someone stitches them	Pull, normalize, and summarize into one consistent view
Repetitive data entry	Copying the same data between two systems that do not talk	An integration moves and validates it without the copy-paste
Knowledge in one head	Key answers live only with one long-tenured person	A grounded assistant answers from the real source documents

The last one deserves attention. In most groups, a handful of people carry critical knowledge in their heads: how a specific entity files, why a supplier is treated a certain way, what a clause means. When that person is on holiday or leaves, the group slows down. Capturing that knowledge into a system that answers from your actual documents is not a nice-to-have. It is risk reduction.

How to Pick the First Workflow

Do not start with the most interesting problem. Start with the one that is high volume, repeated across the most entities, and painful enough that people already complain about it. Score your candidates honestly against four questions:

Volume. How many times a week does this happen across the whole group? More is better for a first target.
Repetition. Is the work genuinely the same each time, or does every case need real judgment? Sameness automates well.
Reach. How many entities share this exact workflow? Wider reach means a bigger payback from one build.
Clarity. Can you point to where the correct answer lives today? If the source is clear, the automation is trustworthy.

The sweet spot scores high on all four: lots of volume, very repetitive, shared by most of your companies, with a clear source of truth. Document intake usually fits, which is why it is where I most often begin. If you want to go deeper on that area, I wrote a full guide to intelligent document processing that walks through it.

Why a Shared Grounded-AI Layer Beats Point Tools

Here is the trap. Each entity, left to itself, buys or bolts on its own point tool: one for invoices here, one for a chatbot there. Within a year the group has a dozen disconnected tools, a dozen bills, and no shared memory. Nothing learns from anything else.

The better pattern is one shared layer that every entity plugs into. Build the document understanding, the extraction, and the question-answering once, as a common service, and let each company feed it their documents. When you improve the layer, every entity gets the improvement at the same time. When you add a new company to the group, it connects to something that already works.

Critically, this layer has to be grounded. Grounded means the AI answers only from your real documents and cites where each answer came from, rather than producing confident guesses. My rule on every build is simple: cite the source or cut the claim. For a founder making real decisions across multiple entities, an assistant that invents a number is worse than no assistant at all. Grounding is what makes the output safe to trust.

The Single Source of Truth

A shared layer only works if the group agrees on where the truth lives. Today, in most multi-entity setups, the truth is scattered: some in a folder, some in an email thread, some in one person's memory. The automation project is often the first time a group is forced to answer a healthy question. For each type of information, what is the one authoritative source?

You do not need to consolidate everything into one giant system to get this. You need each important data type to have a clear home that the AI layer reads from. Once that home exists, every entity, every report, and every answer traces back to the same place. That is what stops two of your companies from quietly reporting the same thing two different ways.

Prove It With One Scoped Pilot

Do not roll AI across the whole group on faith. Pick one workflow in one or two entities and run a tightly scoped pilot. A good pilot is one to two weeks, has a number attached to it that you can check yourself, and ends with a working system on your real documents, not a slide deck.

This is exactly how I work. A paid proof pilot starts from 2,500 dollars, runs in one to two weeks, and is credited toward the full build if you proceed. You see the thing working on your own data before you commit to rolling it across the group. From there, a fixed-scope build typically runs 8,000 to 25,000 dollars, or you keep me on as a fractional AI engineer from 4,000 dollars a month. Everything is async, with a written intake and no calls required.

The proof matters more here than in a single business, because a multi-entity rollout multiplies both the upside and the risk. Prove the pattern once, cheaply, on real documents, then reuse it with confidence. I have built exactly this kind of grounded, cited system twice over. Deal OS reads messy deal documents and answers with citations back to the source. Amy answers product questions off a live data source without inventing anything. Both are real, shipped systems, not demos.

Where to Start This Week

List your entities. Write down the one document or data workflow that appears in the most of them. That is almost certainly your first target. If you want a second opinion on which workflow to pick, or a scoped pilot to prove it, send me the details through the async intake. No call needed. Just tell me what your group repeats by hand, and I will tell you honestly whether it is worth automating.

Start here: Custom AI & Python development. Or send your workflow straight to the async intake.

Custom AI Development for Founders

DEVALAND — Thu, 06 Aug 2026 14:00:06 +0000

Off-the-shelf AI is enough when a wrong answer is cheap and a human checks the output anyway. It stops being enough the moment the AI touches your real documents, your numbers, or a regulated decision, because a generic model will answer confidently even when it is wrong. A custom build fixes that with retrieval, citations, human approval, and evaluation, so the system either backs up a claim with a source or does not make the claim at all.

That last line is the whole article. Everything below is how you get there, when it is worth it, and how to find out cheaply before you commit a full budget.

Wiring up a chatbot is not building an AI system

Most "AI features" you see are a text box wired to a model API. You type, the model answers, done. That is a demo, and demos are useful. The problem is that a demo has no idea what is true. It was trained on the public internet up to some cutoff date, and it has never seen your lease agreements, your lab results, your cap table, or last month's numbers.

Ask a generic tool a question about your business and it does one of three things: it answers from stale general knowledge, it answers from whatever you happened to paste into the window, or it fills the gap with a plausible invention. The third one is the dangerous one. The model does not signal doubt. A fabricated clause and a real clause come out in the same calm, formatted sentence.

For a marketing first draft, fine. For a diligence memo, a compliance summary, or a customer-facing price, a confident wrong answer is worse than no answer, because someone acts on it.

Why generic tools hallucinate on your data, and how a real build stops it

Hallucination is not a bug you patch. It is what a language model does by default when it has no grounding. The fix is architectural. A production system is built so the model can only speak from material you control, and so its claims are checkable.

Here is the machinery a real build puts around the model.

Retrieval. Your documents are indexed so that, for any question, the system pulls the exact passages that matter and puts them in front of the model as the source material. The model answers from those passages, not from memory. This is retrieval-augmented generation, and it is the difference between "the model thinks" and "the model read your file and reported what it said."

Citations. Every claim links back to the specific source it came from: this document, this page, this line. If the system cannot find a source, it says so instead of guessing. On the Deal OS platform I built this on a single rule: cite the source or cut the claim. A sentence that cannot point to a document does not ship.

Human approval. For anything that carries real consequence, the AI drafts and a person signs off. The system is built to make that review fast, by showing the evidence next to the claim, not to remove the human from the loop.

Evaluations. Before it goes live and every time it changes, the system is tested against a set of known questions with known correct answers, so you can measure accuracy instead of hoping. Without evals you are shipping vibes. With them you have a number you can defend.

The same pattern shows up in Amy, a grounded voice assistant I built for a Shopify brand. Amy answers product questions and quotes live prices, and she pulls those prices from the store's real catalog on a daily sync rather than inventing a number that sounds right. A wrong price on a live call is a refund and a lost customer. Grounding is not a nicety there. It is the product.

Build versus buy

Buying is the right default. If a proven tool already does the job, buy it and move on. The honest question is not "could custom be better" but "is the gap between what you can buy and what you actually need wide enough to pay for."

Situation	Lean buy	Lean build
The task is generic (draft emails, summarize public text)	Yes	No
The AI must answer from your private documents and data	Sometimes	Usually
A wrong answer has legal, financial, or regulatory cost	No	Yes
It must plug into your existing systems and workflow	Rarely clean	Yes
You need to own the logic, the data path, and the audit trail	No	Yes
You are one of many identical customers of a SaaS tool	Yes	No

A useful middle path exists and I use it often: build a thin custom layer on top of bought parts. You do not rebuild the language model or the database. You build the retrieval, the grounding rules, the approval flow, and the integration that make a general model behave correctly on your specific data. That is where most of the value sits, and it is far less work than people assume.

What a real custom AI build actually includes

When I scope a build, it is not just a prompt. It is a system that has to be right on a Tuesday when no one is watching. A typical build includes:

Document ingestion: OCR and extraction that turn PDFs, scans, and mixed formats into clean, structured, searchable data.
A retrieval layer over your content so answers are grounded in your material.
Grounding and citation logic that ties every claim to a source and refuses when there is none.
Human-in-the-loop review for anything consequential.
An evaluation suite so accuracy is measured, not assumed.
Integrations that snap onto the systems you already run, instead of forcing a new tool on your team.
Guardrails: rate limits, cost caps, access control, and an audit trail.

That list is the same whether the surface is a chat box, a voice assistant, or a background job that reads a folder of contracts and flags the risky ones. The interface changes. The discipline underneath does not.

How to de-risk the whole thing with a paid pilot

The fear with custom software is spending real money on something that might not work. The answer is to not commit the full budget up front. Start with a paid proof pilot: one narrow, high-value slice of the problem, fixed scope, roughly one to two weeks, from $2,500, and the cost credits toward the full build if you proceed.

A pilot answers the only questions that matter before a bigger spend. Does the retrieval actually find the right passages in your documents. Is the accuracy good enough on your real material, measured against known answers. Does it fit how your team already works. You see a working thing on your own data, not a slide deck, and then you decide.

From there the shape is simple. A fixed-scope build typically runs $8,000 to $25,000 depending on surface area. If you would rather have an AI engineer embedded for ongoing work, that is fractional from $4,000 per month, or a day rate from $750. Intake is async and written. There are no sales calls.

For a deeper look at the document side of this, see the guide on Intelligent document processing. If you are weighing embedded help over a one-off project, Hire a fractional AI engineer walks through that model. And AI Deal OS is the platform where the cite-the-source rule runs in production every day.

The short version

Generic AI is a fast first draft with no sense of what is true about your business. A custom build adds the parts that make it trustworthy: it reads your actual documents, cites its sources, asks a human before anything consequential, and is measured against known answers. If the AI cannot back a claim, it should cut the claim. Build that, prove it on a small paid pilot, then scale what worked.

If you have a document-heavy or data-heavy workflow where a wrong answer costs real money, that is exactly the kind of problem this is built for. See Custom AI & Python development for how the builds are scoped, and start the async intake at /contact?service=ai-build. No calls, no pitch, just a written back-and-forth about whether a build makes sense for you.

My AI Feature Was Dead for a Day. The Metric Said It Was Working.

DEVALAND — Tue, 04 Aug 2026 14:15:43 +0000

Yesterday my drone early-warning demonstrator recorded four AI-generated explanations. All four were discarded by the validation gate that sits in front of them.

I looked at that number and felt good about it. A gate that rejects four out of four is a gate doing hard work. It is exactly the statistic I would put in a technical brief.

It was wrong. Not the gate. My reading of it.

What the system does

The demonstrator fuses signals from several sources and decides a threat level using deterministic rules. No model touches that decision. A local language model is then allowed to do one thing: rewrite the machine's reasoning into a sentence an operator can read at speed.

Because a small local model is not reliably obedient, the sentence is checked before anyone sees it. It has to name the threat level the rules computed, and no other level. Anything else is thrown away and the deterministic wording stands. I tested that gate when I built it. Seven of twenty-five sentences were unfit for an operator display. After adding the gate, thirty out of thirty conformed.

So when the production counter said zero of four survived, the story wrote itself. Sporadic escalations, a small model, a strict gate. Of course some get discarded.

The counter was measuring two different things

The function that calls the model returns nothing when the gate rejects the text. It also returns nothing when the model does not answer at all. Timeout, connection refused, anything. Both cases came back as the same empty result, and I recorded both as "rejected by the gate."

That is the whole bug, and it is not really a coding mistake. It is a naming mistake. I gave one counter to two different facts.

One of those facts says the safety mechanism is working. The other says the feature is dead. They are opposites, and I had made them indistinguishable.

What was actually happening

The model runs locally on the same machine, which is the point: an operational deployment sits on a network with no route to a commercial API. The runtime unloads an idle model from memory to free it up. Reloading two gigabytes on four CPU cores takes longer than the thirty second timeout I had set.

Escalations are sporadic by design. The system is quiet most of the time. So nearly every escalation arrived to find the model cold, waited thirty seconds, gave up, and fell back to the deterministic wording.

Warm, the same prompt answers in 7.8 seconds and passes the gate on the first try. I measured it directly against the running model, with the exact production prompt, after the diagnosis.

The feature had not failed. It had never run.

The fix took ten minutes. Finding it took the audit trail

Three changes. Ask the runtime to keep the model resident so a quiet hour does not guarantee the next escalation fails. Raise the timeout well past a cold load, since a slow answer costs nothing when the fallback is already correct. And split the counter into four: accepted, rejected by the gate, empty, never answered.

That last one is the change that matters. The first two are configuration. The third is the difference between a number you can act on and a number that comforts you.

I would not have found any of it without something I had built the same afternoon: durable history, so every assessment is written to disk with what the rules decided, what the model said, and whether its sentence survived. That storage layer existed for a completely different reason. It was built so a host site could eventually be handed a measured false alarm rate. Four hours after it went in, it told me the headline AI feature had been inert for a day.

The second thing it caught

Once the model started answering again, one of its sentences read: "at HIGH confidence level justifies the HIGH threat level."

The gate accepted it, correctly by its own rule, because it names the computed level and no other. But look at what the sentence asserts. The system computes a confidence per detector. It never computes an aggregate confidence about anything. That sentence states a measurement nothing in the system produced.

The prompt already forbade it. The instruction is right there in the system message, and the model ignored it, which is the entire reason a gate exists instead of trust.

So the gate now rejects that phrasing rather than tolerating it. One existing test asserted the old, permissive behavior. I flipped it deliberately and wrote down why, because a test that quietly changes meaning is worse than no test.

What I would take from this

If you run a model in production behind any kind of check, the useful question is not how often the check fires. It is whether you can tell the difference between the check firing and the model never answering.

Those look identical from the outside. Both produce no output. Both leave your fallback in place. Both can be reported as a single tidy number that makes your safety mechanism look busy.

Instrument the difference. A counter that merges a working safeguard with a dead dependency is worse than no counter, because it does not stay silent. It reassures you.

The uncomfortable part is that my failure mode was the same one I write about: a confident output with nothing real behind it. It just happened to be a metric rather than a model.

A note on what this system is, because it matters in this category. DroneWatch AI is a working concept demonstrator. The threat signals are simulated. The air traffic feed is live and real. It is not an operational system, it does not detect real drones, and no field validated performance is claimed. It is strictly defensive, detection and early warning only, with no interdiction or countermeasure function.

Why a Scan Is Not a Document

DEVALAND — Tue, 04 Aug 2026 03:31:52 +0000

In the previous piece I argued that a PDF keeps where the glyphs sit and throws away what they meant. A scan is a harder case, because a scan does not even have glyphs. It has pixels. Everything else is reconstructed by software that is guessing, and the guessing is much better than it used to be, which is exactly what makes it dangerous.

More than twenty years of setting scientific books taught me what a table actually is. It is not a picture of rows and columns. It is a grid of relationships: this number belongs to this row label and this column header, and it means nothing at all detached from either. Publishers rebuild tables by hand when they come in as images, and they do it because there is no honest shortcut.

That is the whole argument of this post. OCR converts pixels into characters. It does not convert a page back into a document.

OCR errors are not random, and that is the problem

If OCR failed noisily, this would be a solved problem. You would see garbage, you would know.

It does not fail that way. It fails toward plausibility. A 6 becomes an 8. A 1 becomes a 7. A 5 becomes an S. A comma becomes a full stop, which in a European financial document turns 1.234 into 1,234 or the reverse. The engine is choosing the most likely character given the shape, and the most likely character is almost always a real one.

In prose, this is survivable. You read a sentence with one wrong letter and your brain corrects it without stopping. That is why OCR feels so accurate: you are testing it on text where you are the error correction.

In a table of figures there is no such redundancy. Every digit is load-bearing. Nothing in the surrounding context tells you that a margin should be 6.2 rather than 8.2. The wrong number is exactly as readable as the right one, carries the same confidence, and looks equally like a fact.

Where scanned tables actually break

Four failure modes, and I have seen all four in real documents.

Column drift. A value lands one column to the left or right of where it belongs. Revenue for 2024 is now sitting under 2023. The total still adds up, because the same numbers are present, just attributed to the wrong period. Nothing looks wrong until someone builds a growth rate from it.

Tables that continue across pages. In a printed book this is handled by repeating the header and adding a continuation rule. OCR sees two separate blobs on two separate pages, and unless something explicitly stitches them, half the table silently disappears or becomes its own orphan table with no headers at all.

Merged and spanning cells. A header that spans three columns, or a row label that covers two rows, is a relationship expressed purely through geometry. Flatten it and the relationship is gone. The value that belonged to all three sub-columns now belongs to one of them, or to none.

Rule lines read as characters. A thin vertical rule becomes a 1 or a pipe. A horizontal rule becomes a row of dashes or underscores that the parser treats as content. This one is easy to spot when you look and impossible to spot when you do not.

The confidence score will not save you

Most OCR engines return a confidence value, and it is tempting to gate on it. Below some threshold, flag; above it, trust.

It does not work, for the same reason it does not work in retrieval. The confidence is per-character and it measures how sure the engine is about the shape it saw, not whether the resulting document makes sense. A crisp, clean, high-confidence 8 that was actually a 6 scores beautifully. A slightly smudged but correctly read digit scores worse. The score is orthogonal to the thing you care about.

I measured a version of this problem in a different context and published the result: retrieval similarity scores could not separate answerable questions from unanswerable ones, because the two populations overlapped. The lesson is the same here. Anything computed before you have the answer cannot tell you whether the answer is right. The check has to happen afterwards, against the source.

What to do instead

The habit is the same one that governs everything else I build. Treat the scan as evidence of a document, not as the document.

Keep the page image, always. If a figure is ever questioned, the answer is not a log line, it is the picture of the page it came from. This is the scanned-document version of a citation.

Rebuild tables as tables, and keep them that way through the entire pipeline. A table flattened into prose has lost the row-to-column relationship, which was the only reason the table existed.

Require every number to be findable in the source. Not paraphrased, not approximately present. Findable. If it cannot be located verbatim on the page it claims to come from, it does not get repeated.

Say the input was a scan. Put it in the output where the reader sees it, not in a log nobody opens. A brief built from clean born-digital PDFs and a brief built from a photocopied fax deserve different levels of trust, and the reader is entitled to know which one they are holding.

Never repair a number quietly. If something looks wrong, flag it and show the source. Correcting it invisibly means the next person inherits your guess as a fact.

Why this matters outside publishing

Publishers already know all of this. They budget for it, they employ people who rebuild tables by hand, and they treat a scanned manuscript as a cost rather than a convenience.

The people who get hurt are the ones who assume a PDF is a PDF. An acquirer reading management accounts that were scanned from a printout. A lender working from a photographed set of statements. Anyone whose most important number arrived as an image of a number.

The document you were sent and the document your software read are not always the same document. With a born-digital file, the gap is small. With a scan, it can be a decision made on a digit that was never there.

Cite the source or cut the claim. And when the source was a photograph of a page, say so out loud.

What 70 Scientific Books Taught Me About Why AI Misreads a PDF

DEVALAND — Tue, 04 Aug 2026 03:31:47 +0000

My name is printed in the front matter of more than seventy scientific volumes, and I have spent more than twenty years turning manuscripts into typeset pages. I now build AI systems that read documents for a living. Those two facts sound unrelated. They are the same problem seen from opposite ends, and the first one explains most of what goes wrong in the second.

Here is the short version. A document that has been typeset is not a bag of words. It is a structure, and almost all of that structure is thrown away the moment it becomes a PDF. When an AI reads that PDF, it is not reading the document. It is reading the shadow the document left on a page.

What a typesetter actually does

Setting a scientific book is not decoration. It is the act of encoding meaning into position.

A running head tells you which chapter you are in without reading a word. A float, a table or figure that moves to wherever it fits, carries a caption precisely because it has been separated from the paragraph that referred to it. Front matter is a defined sequence: half title, title, copyright, dedication, contents, preface. A displayed equation is numbered because something later will point back at it. A footnote sits at the bottom of a page and a citation sits in a bibliography, and those are different objects doing different jobs.

None of that is styling. Every one of those decisions is semantic. The compositor's craft is knowing that a two-line gap and a smaller point size mean this is an aside, not the argument, and that a reader will absorb that without ever being told.

In LaTeX, the source knows all of this explicitly. There is a \chapter, a \caption, a \label, a \cite. The structure is not implied by how it looks. The structure is written down, and the appearance is derived from it.

What the PDF keeps

The PDF keeps the appearance and discards the source.

A PDF is a set of instructions for placing glyphs at coordinates. Put this character at this x and y, in this font, at this size. That is essentially all it is. The fact that a particular run of glyphs was a chapter title, and another was a caption, and a third was a footnote, is not recorded anywhere. It is inferable by a human because humans read layout fluently. It is not stated.

So when a system ingests that PDF, it has to reconstruct, by guesswork, everything the compositor originally knew for certain. Is this larger text a heading or an emphasised sentence? Does this two-column page read left column then right, or across? Is this number a footnote marker or an exponent? Does this table have a header row, or is the first row just bold?

Every one of those guesses is a place where a document quietly becomes a different document.

The failures I see, and why they are structural

Three show up constantly, and none of them is a model problem.

Reading order. Two-column layouts are the classic. Extraction that follows the coordinate stream rather than the column flow will interleave the two columns line by line. The output is grammatical, fluent nonsense. Nothing errors. The text is all there. It is simply in an order that never existed.

Orphaned captions and floats. Because a float moves, a table can be printed pages away from the sentence that discusses it. Flatten that and the table arrives with no context, or worse, glued to whatever paragraph happened to be adjacent on the page. A figure that supports one claim gets silently attached to another.

Footnotes folded into the body. A footnote is a qualification, very often the exact qualification that limits the claim above it. Merge it into the running text and you get a sentence that asserts something the author deliberately hedged.

I want to be precise about the point. These are not hallucinations. The model is faithfully reporting what it was given. It was given a scrambled document.

Scans are a different problem again

Everything above assumes a born-digital PDF, where the glyphs are real characters. A scan is worse, because there are no characters at all, only pixels, and OCR has to invent the text before anything can read it.

OCR is very good now. It is not good at deciding that this block is a table and this one is a paragraph, and it has no idea that page 14 is a continuation of the table on page 13. In practice, tables are where scanned documents do the most damage, because a number lifted out of a misread table looks exactly as authoritative as a number lifted out of a correct one.

This is why "just OCR it" is not a plan. OCR converts pixels to characters. It does not convert a page back into a document.

What I do about it

The habit that came out of typesetting, and that I now build into software, is this: treat structure as evidence, and treat its absence as a fact worth recording.

Concretely, in the systems I build for reading commercial and financial documents:

Reconstruct reading order deliberately rather than trusting the coordinate stream. Column detection first, then flow.

Keep tables as tables through the whole pipeline. A table flattened into prose has lost the relationship between a row label and its value, and that relationship is usually the entire point of the table.

Carry the location with the content. Every extracted claim keeps the page it came from, so a reader can go and look. This is the same discipline as a citation in a bibliography, and it exists for the same reason.

Cut what cannot be traced. If a figure cannot be tied back to a specific place in a source document, it does not get repeated. It gets flagged. A missing number is an inconvenience. A confident wrong number is a decision made on fiction.

Say when the input was poor. If a document arrived as a low-quality scan, that belongs in the output, not buried in a log. The reader is entitled to know how much to trust what they are looking at.

The part that transfers

Typesetting taught me that most of what a document means is carried by how it is arranged, and that this arrangement is invisible until you try to reproduce it mechanically. More than twenty years of putting structure into pages turns out to be unusually good preparation for the problem of getting structure back out of them.

The people who feel this most sharply are not publishers. They are anyone who has to make a decision from a hundred-page document that arrived as a PDF: an acquirer reading a data room, a lender reading management accounts, an analyst reading a filing. The document they were sent and the document their software read are not always the same document, and nothing in the process tells them so.

That gap is the whole reason I build the way I do. Cite the source or cut the claim, and when the source itself was damaged in transit, say that out loud.

Intelligent Document Processing: A Practical Guide

DEVALAND — Mon, 03 Aug 2026 14:00:06 +0000

Intelligent document processing (IDP) is the practice of turning messy documents (PDFs, scans, emails, spreadsheets) into structured, validated data that flows into your systems without a human retyping it. In 2026 the useful version pairs classic OCR with language models for extraction and reasoning, then wraps both in validation and human review so the output is trustworthy. This guide covers the real pipeline, where LLMs earn their keep, where they hallucinate, and how to start small on one document type.

What IDP actually is now (beyond old OCR)

Old OCR answered one question: what characters are on this page. That was useful and still is, but it left you with a wall of text and a person to read it. IDP answers the harder question: what does this document mean, and which specific fields do I need out of it.

The shift is that extraction is no longer just pattern matching on fixed templates. A modern pipeline can read an invoice it has never seen before, a lab report in an unfamiliar layout, or a 120 page information memorandum, and pull the fields you asked for. That flexibility is what makes IDP worth doing. It is also what makes it dangerous if you skip validation, because a system that can read anything can also confidently invent things.

The real pipeline, stage by stage

A working IDP system is not one model. It is a short assembly line, and most of the reliability lives in the boring stages, not the clever one.

Ingest any format. Documents arrive as native PDFs, scanned images, photos from a phone, email attachments, Excel files, and the occasional Word doc. Stage one normalizes all of it and detects the document type so the right rules apply downstream.

OCR and layout. Scanned and image based pages go through OCR that preserves layout: tables, columns, headers, and where each value sits on the page. Position matters, because knowing that a number lived in the total row of a table is what lets you trust it later.

Extract structured fields. This is where a language model shines. You define the exact fields you want (invoice number, net amount, counterparty, effective date) and the model returns them as structured data, even across layouts it has never seen.

Validate. Every extracted value gets checked against rules: types, ranges, cross totals that must add up, dates that must be plausible, references that must exist. Anything that fails validation is flagged, not silently passed on.

Route into systems. Clean, validated records go where they belong: your accounting tool, your database, a CRM, a review queue. Low confidence or failed items go to a human instead of into your books.

Stage	Job	Main risk if skipped
Ingest	Normalize formats, detect type	Wrong rules applied to wrong doc
OCR and layout	Read text, keep structure	Values read out of context
Extract	Pull the fields you defined	Missing or malformed data
Validate	Catch impossible values	Silent errors reach systems
Route	Send clean data onward, flag the rest	No accountability, no audit trail

Where LLMs help, and where they hallucinate

Language models are very good at reading unfamiliar layouts, handling synonyms (net, subtotal, amount due), summarizing dense sections, and answering questions about a document. For extraction across varied formats, they remove months of brittle template work.

They are bad at three things that matter here. They fill gaps: when a field is missing, a model would rather guess a plausible value than say it is absent. They misattribute: they can pull the right number from the wrong row or the wrong entity. And they drift on arithmetic: totals and derived figures are not safe just because they look right.

The fix is not a better prompt. It is architecture. The rule I build to is simple: cite the source or cut the claim. Every extracted value should carry a pointer back to where it came from (page, table, coordinates), and anything the system cannot ground gets marked unknown rather than invented. That single discipline is the difference between a demo and something you can put near real money.

Why citation and human review are non-negotiable for regulated work

If you process financial statements, contracts, clinical or diagnostic documents, or anything a regulator or an auditor might question, you need to answer one question at any time: where did this number come from. A summary cannot answer that. A cited value can, because it points back to the exact line on the exact page.

Human in the loop is not a failure of automation, it is the design. The goal is to automate the 80 percent that is clean and route the ambiguous 20 percent to a person with the source shown next to the extracted value, so a review takes seconds instead of a full manual re-read. You get most of the speed and keep all of the accountability. This is exactly the muscle behind Deal OS, which ingests 100 page CIMs, runs OCR and extraction, and returns cited findings under a verify-not-summarize rule so a buyer can trust what they read.

Build versus off-the-shelf IDP tools

Off-the-shelf IDP platforms are a reasonable starting point when your documents are high volume and standard (think generic invoices or receipts) and you are happy to live inside their templates, their data model, and their per-page pricing.

A bespoke build wins when your documents are non-standard, when the fields you care about are specific to your business, when the data has to land inside systems you already run, or when confidentiality means you cannot ship sensitive files to a third party. Roll-ups, multi-entity groups, diagnostics companies, and M&A acquirers usually fall on the build side because their documents and their downstream systems are theirs alone.

A short, honest test: if a generic tool covers 90 percent of your case, buy it. If the last 10 percent is where all your risk and cost live, that 10 percent is the whole point, and it needs a build.

How to start: one document type, one scoped pilot

Do not try to process everything. Pick the single document type that costs you the most time or the most risk today: one invoice format, one contract type, one report. Define the exact fields you need out of it and what a validated record looks like. Then build the full pipeline for that one type, with citation and a review queue from day one.

That scoped pilot tells you the true accuracy on your real documents, your genuine exception rate, and the actual time saved, before you spend on a wide rollout. Once one type works end to end, adding the next is mostly configuration, not a new project.

This is how I work with founder-operators: a paid proof pilot from $2,500 over one to two weeks (credited to the full build), fixed-scope builds from $8,000 to $25,000, or fractional from $4,000 per month. Async intake, no calls.

If you run an ops-heavy business drowning in documents, see Custom AI & Python development for how these builds are scoped, read more on custom AI development for founders and AI automation for multi-entity founders, or look at AI Deal OS to see cited document intelligence in production. When you are ready, send the details through the async intake at /contact?service=ai-build and we can scope a pilot on your hardest document type.

A Driver's License Question Beat Every Real One: Why Retrieval Scores Cannot Gate a RAG System

DEVALAND — Thu, 30 Jul 2026 14:00:06 +0000

Most retrieval-augmented generation systems carry a comfortable assumption. If the retrieval score is high, the retrieved context is probably relevant and the answer is probably grounded. If the score is low, the system is out of its depth and should refuse. Set a threshold somewhere sensible, and you have a safety mechanism.

I built a small Romanian question-answering system, measured that assumption, and it did not survive contact with the data.

This piece is the measurement, the reason it breaks the standard design, and what I ended up gating on instead. The code is public and the result is reproducible in about a minute on a laptop: ro-cited-answers on GitHub.

What the system is

A question-answering demo over five documents on Romanian customs and EORI registration procedure, drawn from public information published by Poșta Română and the Romanian Customs Authority.

Everything runs locally. An open-weight 2B model on Ollama, an embedding model for retrieval, on a four-core VPS in the EU. No external API, no key, no data leaving the machine. The design rule is that an answer which cannot be traced to a source document is refused before anyone reads it.

I did not build it as a product. I built it because a parcel of mine was genuinely stuck in customs at BSI București, and the questions in the test suite are the ones a real person actually needed answered.

The measurement

The script scores seven legitimate questions and seven impostors against the corpus. Legitimate questions are about customs, EORI numbers, parcel returns. Impostors are about things the corpus knows nothing about.

If a retrieval score is a usable safety signal, the two populations should separate cleanly. Every real question should score above every impostor, and the gap between them is where you put the threshold.

They do not separate. They overlap.

	Question	Score
Lowest legitimate	"Cand am nevoie de cod EORI pentru un colet?"	0.697
Highest impostor	"Ce documente imi trebuie pentru un permis de conducere?"	0.773
Separation margin		-0.076

A question about driver's license paperwork scored higher against a Romanian customs corpus than every genuine customs question did.

The margin is negative. That is the whole finding. It is not that the threshold was badly tuned, or that a bit more calibration would fix it. When the populations overlap, there is no value you can pick that admits every real question and rejects every impostor. One threshold is too strict and loses real answers. Any looser one lets the driver's license question through.

Why this breaks the common design

A lot of RAG systems treat the retrieval score as the guardrail. Retrieve, check the similarity, and if it clears the bar, hand the context to the model and trust that grounding follows.

If the score cannot distinguish a question your corpus can answer from one it cannot, then that guardrail is decorative. It will fire on some things and feel like it is working, which is worse than not having it, because it produces confidence without producing safety.

Note what the impostor question does. It is in the same language, the same register, the same bureaucratic domain of official documents and required paperwork. Embeddings capture that similarity faithfully. They are doing their job. Asking a similarity score to also tell you whether a specific fact is present in a specific document is asking it a question it was never designed to answer.

So in this system the retrieval gate is deliberately not load-bearing. Its threshold is set from the measurement above, it catches the obviously unrelated case, and nothing important rests on it.

What to gate on instead: the answer, not the confidence

If you cannot trust a score computed before the answer exists, check the answer itself after it exists.

Four gates run in sequence, and an answer must clear all of them or it is refused, with the refusal logged.

Gate A, retrieval. The best-matching document must clear a similarity threshold. Deliberately weak, for the reason above.

Gate B, citation. Every source the model points at must resolve to a document that was actually retrieved. Catches invented citations.

Gate C, numbers. Every number in the answer must appear verbatim in a cited source. Numbers are where a hallucination does financial damage, and they are cheap to check exactly.

Gate D, grounding. Every substantive sentence must be attributable to one cited document, and the printed source list is rebuilt from the documents that actually carried a sentence.

Gate D is the load-bearing one, and the reason is worth stating plainly.

Gates that depend on the model cooperating with an instruction are brittle. You can tell a model to cite its sources in a particular format, and a large model will usually comply, and a 2B model frequently will not. Gate D does not ask the model for anything. It takes the answer as a finished artifact and checks it against the source text. It works the same whether the model cooperated, ignored the instruction, or never understood it.

That is the transferable idea here, and it is the same rule I run in production diligence work: cite the source or cut the claim. Check the output against the evidence, not the model against its instructions.

The same model, twice, minutes apart

Here is what the gates are actually for.

Ungrounded, asked what EORI means, the model answered that it is a "European Union Chamber of Commerce and Industry Number."

That is invented. EORI is not a chamber of commerce number. The answer is fluent, plausible, correctly shaped, and wrong, which is the exact failure mode that costs money in regulated work.

Grounded through the four gates, same weights, same machine, minutes later, it answered that EORI stands for Economic Operators Registration and Identification, that the number is assigned free of charge, and that the average processing time is 5 days with a maximum of 30. Then it printed the source document and the date that source was last checked.

Same model. Same hardware. The gates decided everything.

This is also why I am unconvinced by the framing that sovereign AI, by itself, gets you trustworthy AI. There is a serious argument in Europe about open weights, national compute, and models governed under national law, and it is worth winning. But sovereignty decides where the weights sit. It decides nothing about whether a particular answer is true. A model can be entirely sovereign and confidently wrong at the same time.

Three things that cost real time

A small model will not echo a string source id. Asked to cite a document by its identifier, the model answered the question correctly and signed it "SURSE: 1, 2." A gate demanding string ids threw away two correct answers. The fix was to number the fragments and map the number back to the real document in code, where it cannot be got wrong. If a gate can be enforced in code instead of in a prompt, enforce it in code.

Once citing is cheap, models pad their citations. With numbered fragments, the model answered a parcel-return question correctly from the right document, then also cited an unrelated one. The answer was trustworthy and the citation list was noise, which is precisely backwards for a system whose entire value proposition is traceability. Citations are no longer taken on the model's word. Each sentence is attributed to its best-matching cited document, the printed list is rebuilt from what actually carried a sentence, and padding is stripped and logged.

Morphology is not ungroundedness. Romanian inflects heavily. Exact word matching scored a verbatim quote at exactly 0.5000 against a 0.50 threshold, which passed only because the comparison was written as less-than rather than less-than-or-equal. That is not a safety margin, that is luck. Prefix matching on content words lifted the same quote to 0.83, while a genuinely ungrounded sentence still scored 0.00.

Every decision, accepted or refused, is appended to an audit log with the retrieval scores, the gate that fired, and the per-sentence attribution. A refusal you cannot reconstruct afterward is just a different kind of unverifiable output.

What this does not do

I would rather state the limits than have you find them.

It is slow. CPU-only inference on four shared cores runs at roughly 2 tokens per second. Fine for a demonstration, not fine for production traffic.

The grounding is lexical, not semantic. Gate D compares content words by a fixed-length prefix, so it forgives Romanian inflection but not synonymy. A correct paraphrase sharing little vocabulary with its source would be refused. The system fails toward refusing, which is the right direction, but it is a real limitation and not a subtle one.

The corpus is five documents. The overlap finding in particular should be re-measured on a larger corpus before anyone treats it as a general result. I am reporting what I measured, not a law of nature.

A refusal is not an answer. Refusing well is the point, but a system that refuses everything is also useless. Of the four test cases, two must be refused and two must be answered, precisely to hold both sides honest.

None of this is legal advice, and the corpus is a demonstration fixture.

The part worth taking away

If you are building anything that answers questions from documents and the stakes are higher than trivia, the question to ask about your own system is simple. When it refuses, what is it actually checking?

If the answer is a retrieval score, go measure whether your in-corpus and out-of-corpus questions actually separate. Score a handful of real questions and a handful of plausible impostors from an adjacent domain and look at the two populations. It takes an afternoon. You may find, as I did, that the number you have been trusting cannot tell the two apart.

Then move the check to where it can be enforced: the finished answer, against the source text, in code.

That is the same discipline behind the diligence work we do, where a figure in a hundred-page deal document either traces to something real or it gets flagged rather than repeated. If you want to see it applied to acquisition documents instead of customs procedure, there is a cited sample brief with every claim tied to its source, no login required.

The repository is MIT licensed and the measurement script is the first thing worth running: github.com/MariusGithub13/ro-cited-answers.

AI on the Data, Human on the Judgment: Where AI Belongs in Diligence

DEVALAND — Mon, 27 Jul 2026 14:00:05 +0000

There is a simple test for whether AI belongs in your diligence process: does it do the reading, or does it do the deciding? Get that line right and AI is the best analyst you have ever had. Get it wrong and it is a confident intern who never says "I am not sure."

The right division of labour is old, it just has new tools. AI on the data. Human on the judgment.

What "AI on the data" actually means

The data work in diligence is enormous and mechanical: read a hundred-page CIM, pull every figure, find the customer schedule, match the number in the narrative to the number in the appendix, flag where they disagree, and trace each claim to the page it came from. This is exactly what machines are good at and humans are slow at. Done well, it turns a week of reading into an afternoon of reviewing, and it does not get tired on page 80.

The key constraint is citation. AI earns its place on the data only if every figure it reports is tied to a source line, and anything it cannot trace is dropped or flagged rather than filled in. The moment a model is allowed to invent a missing number, it stops being an analyst and becomes a liability, because a plausible wrong number reads exactly like a right one.

What must stay human

Judgment is the part that does not automate. Is this customer concentration a dealbreaker or a discount? Is this owner genuinely replaceable? Does this earn-out protect me or just delay the problem? Do I trust this seller? These are decisions shaped by experience, risk appetite, and things that are not in the data room at all. AI can lay the evidence in front of you, cited and reconciled. It cannot decide what the evidence means for your deal, and it should not try.

The failure mode is treating an AI summary as a conclusion. A clean paragraph feels like an answer. It is not. It is a starting point that still has to be checked and judged.

Where the line pays off

Job	Owner	Why
Read the data room, extract figures	AI	Volume and speed, no fatigue
Reconcile narrative vs schedule vs contract	AI	Mechanical cross-checking
Trace every claim to its source line	AI	Verifiable, not trusted
Decide what changes the price	Human	Judgment, risk appetite
Decide whether to walk	Human	Experience and context

How Deal OS draws the line

Deal OS is built on exactly this split. It reads the data room and produces a brief where every claim traces to its source page, and any figure it cannot verify is discarded rather than guessed. It flags contradictions with both sides cited. What it deliberately does not do is tell you whether to buy. It hands you cited evidence and reconciled numbers so your judgment is spent on the decision, not on the reading. See it on a synthetic deal in the sample brief, or run one of your own CIMs through it for a one-time $99 with the CIM Pass, credited to your first month if you continue.

Frequently asked questions

Can I trust an AI summary of a CIM? Not as a conclusion. Use it as a map: require a source quote for every figure that matters, and treat anything unsourced as a question rather than a fact.

What should AI never do in diligence? It should never fill a gap with an estimate, and it should never make the buy-or-walk decision. Its job is to surface and cite evidence, not to judge.

Does AI replace a quality-of-earnings provider? No. It accelerates the reading and cross-checking, but the judgment calls on normalisation, risk and price stay human.

See what a cited, contradiction-flagging brief looks like on a sample deal at Deal OS.

The Verification Gap: Why Translated Summaries Misprice Cross-Border European Deals

DEVALAND — Thu, 23 Jul 2026 14:00:06 +0000

In a cross-border deal, the risk is not that a number was translated. It is that nobody checked the translation against the original. A German footnote becomes a clean English sentence, an Italian working-capital note becomes a tidy summary, and the version that ends up pricing the deal is the one furthest from the source. The gap between the original document and the summary is where seven-figure mistakes live, and it is exactly the gap a busy buyer is least able to police.

Most cross-border buyers solve the easy half of this problem and skip the hard half. They get the documents translated, read the summary, and feel informed. The value is in the second step almost nobody takes: verifying the handful of numbers the decision rests on against the original-language line they came from.

Language access is the easy part

It is tempting to treat multilingual diligence as a translation problem. Get the German CIM read in German, the French contracts read in French, and the job feels done. But translation is the beginning, not the end. Once a figure is in English it still needs verifying against its source, and that is the step, under time pressure, that quietly disappears. A footnote gets paraphrased into confident English. A working-capital adjustment gets summarised in a way that is technically reasonable and subtly wrong. The summary reads clean. The error is invisible because the reader never returns to the original line.

Why cross-border deals make it worse

This is sharper in Europe than almost anywhere, because the deals are genuinely multilingual in a way many markets are not. A buyer might look at a German manufacturer one month and a French services business the next, each arriving in its own language, with its own accounting conventions and its own footnote culture. And the people one step removed from the documents, the investors and the investment committee, sit even further from the source language than the buyer does. They see the cleanest, most summarised, most translated version of all. The further you sit from the original document, the more confident and the less checkable the number in front of you becomes.

Which numbers actually deserve a second look

You cannot re-read every line of every data room in three languages, and trying to is its own failure: it burns the exclusivity window on figures that do not matter. The discipline is narrower. Verify the handful of numbers your decision actually rests on against the original-language document.

Figure	Why it moves the deal	Check it against
Customer concentration	Sets the risk discount on the multiple	The customer schedule, in the source language
Working-capital peg	Moves the price at closing	The original financial notes, not the summary
Revenue recognition	Changes whether earnings are real	The accounting policy note in its own language
Change-of-control terms	Can un-do the deal after close	The actual assignment clause in the contract

For those, the quote should stay in its original language, so you or someone you trust can check it. If a number cannot be traced back to a specific line, it is not a number yet. It is a question.

A worked example

Consider a manufacturer in a German-speaking country. The English summary of the financials, prepared by an adviser, described a customer concentration that looked acceptable. The original German footnote, read carefully, said something narrower and more alarming: one large customer relationship was contractually softer than the headline implied. The summary was not dishonest. It was a reasonable paraphrase that lost the single qualifier that mattered. A buyer who priced the deal on the English version would have underwritten a concentration risk they never saw, and the investment committee would have approved it without ever seeing the footnote. The reconciliation is what surfaces it.

How Deal OS closes the gap

This is the discipline behind the cited-brief approach in Deal OS. It turns a data room, including documents in other languages, into a brief where every claim traces back to the exact source line it came from, with the original-language passage preserved next to the English so the number can be checked rather than trusted. Where a summary and a source disagree, it flags the contradiction with both sides cited, rather than smoothing it into a clean sentence. You can see it run on a synthetic deal in the sample brief.

Pair this with the management meeting cross-check and the M&A due diligence checklist: the checklist tells you what to verify, the management meeting is where the spoken version drifts, and the verification gap is where the translated version drifts. All three are the same discipline. Treat every summary as a claim until it traces to a source.

Frequently asked questions

What is the verification gap in due diligence? It is the step that gets skipped after a document is translated: checking the English summary against the original-language source. The translating is done; the verifying is not, because the summary is faster to read than the source.

How do I verify a translated financial summary? Identify the few figures your decision rests on, find the specific line in the original-language document that supports each one, and keep the quote in its original language so it can be checked. Numbers that cannot be traced become diligence requests.

Why is cross-border due diligence riskier than single-language diligence? Because every deal arrives in a different language with different accounting conventions, usually without a bilingual analyst to check the translation, and the investors and IC sit even further from the source than the buyer does.

What is source-language citation? It is the practice of tracing each figure back to the original-language passage it came from and preserving that passage, rather than relying only on the translated summary, so the number stays checkable.

See what a cited, contradiction-flagging brief looks like on a sample deal at Deal OS.

The three bugs my AI agent caught before a single customer saw them

DEVALAND — Mon, 20 Jul 2026 18:49:46 +0000

This is a smash story about bugs that never reached a customer, because the thing that wrote them also read them back to me.

I run a small e-commerce store. Its abandoned-cart recovery emails were quietly leaking revenue, so I rebuilt the flow. But I never opened the dashboard. I pointed an AI coding agent at the email platform's REST API and asked it to get the sequence production-ready. Reading the flow, editing the emails, inserting steps, all of it was API calls.

Then it read the generated emails back, and three bugs fell out. None dramatic. All the quiet kind that kill conversion or land you in legal trouble.

Bug 1: the button to nowhere.
The "Complete your order" button linked to a generic /cart page, not the customer's actual saved checkout. The trigger event carried the real checkout URL; the template ignored it. Every recovery email would have sent buyers to an empty cart. Fix: point the button at the event's real checkout URL, with /cart only as a fallback:

href="{{ event.abandonedCheckoutUrl | default: '/cart' }}"

Bug 2: one product shown to everyone.
The email hardcoded a single product, its name, price, and photo. Every abandoner would have seen that same item no matter what they actually left in their cart. That is worse than showing nothing: it is confidently wrong. Here is the human call in the loop: the agent surfaced it, I decided the fix. Generic-but-accurate beats specific-but-wrong, so I cut the hardcoded product rather than guess.

Bug 3: the silent compliance bug.
When the agent inserted the follow-up emails as raw HTML, the platform's branded footer, and with it the unsubscribe link, silently did not attach. An email with no unsubscribe is not just ugly, it is a GDPR and CAN-SPAM problem. Fix: re-send the emails as native blocks so the compliant footer attaches, then verify the unsubscribe actually renders.

The lesson.
I would have skimmed past all three in a nice-looking template. The difference was that the agent read every line back out loud. That is the real defense layer: not that AI writes the thing, but that it shows its work, so the expensive mistakes surface before a user ever hits them. Assume you will slip at 3am, and build the layer that catches it.

The flow is live now. It has not recovered a cart yet, and I am not going to pretend otherwise: the store is new and low-traffic, so nothing real has abandoned through it since cutover. The bugs are the story here, not the revenue. I wrote the whole thing up, rough edges and all, here: https://devaland.com/blog/sequenzy-review-agent-first-email

Disclosure: the email platform in this story is one I reviewed independently. I was given a free account; the write-up was not paid for or approved by them.

Best Due Diligence Software for Acquisitions (2026)

DEVALAND — Mon, 20 Jul 2026 14:00:13 +0000

If you search for "due diligence software," you get two very different kinds of product wearing the same label, and buying the wrong category is how teams end up paying for secure storage when what they actually needed was analysis.

This is a plain-English 2026 buyer's guide for acquirers: search funds, independent sponsors, boutique M&A advisors, and micro-PE teams. It explains the two categories, compares the main tools honestly (including where ours fits and where it doesn't), and gives you a way to choose for the size of deal you actually run.

Quick answer: Most "due diligence software" is a virtual data room (VDR), secure document hosting, permissions, and a Q&A tracker (Datasite, Ansarada, DealRoom, Intralinks). That solves storage and access, not review. A newer category, diligence-automation / document-intelligence tools like Deal OS, actually reads the documents in the room and produces source-cited findings. For a small-to-mid-market deal, the two are complementary: the VDR holds the data room, the automation tool helps you get through it.

The two categories, plainly

1. Virtual data rooms (VDRs)

A VDR is a secure, permissioned place to host the data room and run a buyer/seller Q&A process. Strengths: granular access control, audit trails, redaction, and a defensible record of who saw what. What they generally don't do is analyze the content, a VDR will store a 200-page CIM and forty contracts, but it won't tell you the EBITDA add-backs don't reconcile. Pricing is typically quote-based and scales with data volume and users; historically VDRs are priced for sell-side and larger transactions.

2. Diligence-automation / document-intelligence tools

These read the documents and produce analysis, source-cited summaries, financial extraction, risk and contradiction flags, missing-information checks. The point isn't to store the data room; it's to compress the reading and reconciling that eats most of a diligence timeline. This is the category Deal OS sits in. It does not replace your data room, your QoE provider, or your own verification, it gets you to the real questions faster.

The honest distinction: VDRs manage the documents; diligence-automation tools read them. Many teams use one of each.

At a glance

Tool	Category	Best for	Reads & analyzes docs?	Pricing model
Datasite	Virtual data room	Mid-to-large sell-side M&A	No (storage + Q&A)	Custom quote
Intralinks	Virtual data room	Large enterprise / banking	No (storage + Q&A)	Custom quote
Ansarada	VDR + deal workflow	Sell-side prep, checklists	Limited	Custom quote
DealRoom	VDR + project management	Buy-side process management	Limited	Subscription/quote
Generic AI chat (e.g. uploading PDFs to an LLM)	Ad-hoc document Q&A	Quick one-off questions	Partially, un-audited	Low/free
Deal OS	Diligence automation	Search funds, sponsors, micro-PE buy-side review	Yes, source-cited findings	Published SaaS tiers

Categories and capabilities are described in general terms; verify current features and pricing with each vendor, as products change.

Where each one fits

Datasite and Intralinks are the incumbents for larger, often sell-side transactions where the data room itself is the product and enterprise security and audit trails are the priority. They're robust and expensive, and usually more room than a sub-$10M deal needs.

Ansarada and DealRoom blend a data room with deal workflow, checklists, trackers, and project management, which is genuinely useful on the process side. They still center on managing documents and tasks rather than reading and reconciling the content for you.

Generic AI chat (uploading PDFs to a general LLM) is tempting and cheap, and fine for a quick one-off question. The problem for diligence is trust: answers aren't reliably cited back to the source page, nothing is structured for a data room, and there's no contradiction or missing-information audit. For a decision where a single missed clause changes the deal, "probably right, no citation" isn't good enough.

Deal OS is built for the buy-side review itself. You load a deal workspace, CIM, financials, contracts, tax returns, and the data-room PDFs, and it produces source-cited diligence briefs where every claim is quoted from your own documents and verified before you see it. It ties the same figure out across the CIM, the financials, and the tax return and flags every discrepancy, scrutinizes each EBITDA add-back for whether it survives a sale (a quality-of-earnings first pass), checks a management-call transcript against what the documents actually support, and drafts a buyer-ready investment-committee memo from the verified findings, with risk, contradiction, and missing-information audits across the whole room. It's aimed at the people doing the reading on small-to-mid-market deals, and it's priced on published SaaS tiers rather than a custom enterprise quote. You can try it on a deal that looks like yours in the interactive sandbox, no login, and see exactly what the output looks like.

AI diligence software vs the alternatives

Before you compare tools, compare approaches. On a small-to-mid-market deal a buyer usually weighs five ways to get through the documents, and the honest trade-offs look like this:

Approach	Typical cost	Speed through a data room	What you actually get	Best when
Read everything yourself	Your own hours	Days to weeks per deal	Deep familiarity, but one tired reader, the highest miss rate, and nothing cited for later	You run one or two deals a year and have the time
Hire or borrow an analyst	A salaried hire you usually can't justify before close, or a contractor re-briefed each deal	Faster, bounded by their availability	A second reader, but context resets every engagement and quality varies	You have steady deal flow and budget for headcount
Upload PDFs to a generic AI chat	Low or free	Minutes	Quick answers, but un-cited and un-audited, easy to hallucinate a clause that changes the deal	A throwaway question, never a decision
Commission a formal QoE	Several thousand to tens of thousands per engagement	A week or more	A signed, defensible earnings opinion your lender relies on	At LOI, on a deal you are serious about
Diligence-automation software	A published monthly SaaS tier	Minutes to hours	Source-cited findings, a contradiction map, a tie-out across the CIM, financials and tax return, and a discarded-claims log, every figure traced to its page	You are the buyer and the reading is the bottleneck

Costs are industry-typical ranges, not quotes; they vary by deal size, market, and provider.

These are not mutually exclusive. The pattern most small-to-mid-market buyers settle on is automation software to compress the reading and reach a defensible number, then a formal quality-of-earnings engagement on the deals that clear that bar. The automation is the first pass that makes the paid engagement faster and cheaper, not a replacement for it.

How to choose

A few honest questions cut through it:

Do you need to host a data room, or get through one? If you're running a sell-side process and need permissions and audit trails, you need a VDR. If you're the buyer drowning in documents, you need diligence automation. Many deals want both.
What's the deal size? Enterprise VDRs are priced for larger transactions. For a search fund or micro-PE deal, an enterprise quote is often more room, and more cost, than the deal warrants.
How much of your time is reading? If diligence is mostly reconciling financials and reading contracts against a checklist, that's the part automation compresses. If it's mostly process coordination, a workflow-oriented VDR may matter more.
Can you trust the output? For analysis tools, insist on source citations back to the document. Un-cited AI output can't be defended to an investor or a lender.

What software can't do

No tool closes the deal for you. Software can store the room, read the documents, and surface the questions, but the judgment, the seller conversations, the legal review, and the quality-of-earnings work still belong to you and your advisors. The right software just means you spend your scarce hours on judgment instead of on grinding through PDFs. Pair any tool with a real due diligence checklist so you know what you're verifying, not just where it's stored.

Frequently asked questions

What is the best due diligence software for a small acquisition?
For a search fund, independent sponsor, or micro-PE deal, the better question is which category you need. If you must host and permission a data room, a virtual data room (Datasite, Ansarada, DealRoom) is the tool. If you're the buyer trying to get through the documents, a diligence-automation tool like Deal OS that reads and cites the financials and contracts will save more of your time. Many teams use one of each.

Is a virtual data room the same as due diligence software?
Not quite. A virtual data room (VDR) securely stores the documents and runs the Q&A process, it manages access, not analysis. "Due diligence automation" tools instead read the documents and produce source-cited findings, contradiction checks, and missing-information audits. VDRs manage the data room; automation tools help you get through it.

Can AI do due diligence?
AI can do the document-heavy parts, reading, summarizing, extracting financials, and flagging contradictions across a data room, and produce source-cited findings so you reach the real questions faster. It does not replace your judgment, seller conversations, legal review, or a quality-of-earnings analysis. Treat it as leverage on the reading, not a substitute for verification.

How much does due diligence software cost?
Virtual data rooms are usually quoted custom and scale with data volume and users, which can be expensive for a small deal. Diligence-automation tools like Deal OS are typically priced on published SaaS tiers, so a single buyer can run a deal without an enterprise contract. Always confirm current pricing directly with each vendor.

Should I use due diligence software or hire an analyst?
Before you own a business you usually can't justify a full-time analyst, and a contractor needs the same context re-explained every deal. Diligence-automation software gives you a tireless second reader that cites every figure to its source, for a published monthly price instead of a salary. The honest split is software for the repeatable document reading, and a human (you, your advisors, a QoE provider) for the judgment.

Does AI due diligence software replace a quality of earnings report?
No. It does a QoE first pass: it ties EBITDA out across the CIM, the financials, and the tax return, flags discrepancies, and scrutinizes each add-back for whether it survives a sale, so you reach a defensible number before you commission a formal engagement. The signed QoE opinion your lender and reps-and-warranties rely on still comes from your provider, who now starts from an organized, already-flagged position instead of a cold data room.

Is AI due diligence software worth it?
For a buyer whose main bottleneck is reading, yes: it compresses the slowest phase of a deal from an analyst-week into minutes, and every finding is cited so you can defend it to an investor or lender. The return is not only time saved, it is the missed clause or unreconciled add-back it catches before you wire money. For a pure sell-side hosting need, a virtual data room is the better spend.

See what the output looks like

The fastest way to judge a diligence tool is to look at what it produces. See a real source-cited diligence brief, try it on a deal that looks like yours with no login, or see an example of how Deal OS turns a workspace of documents into cited findings, then decide which category your next deal actually needs. Not weighing a tool yet? Grab the free Deal Kit, 20 cited Claude diligence agents you can run on your own deals today.

Fix: WebP og:images silently break Medium imports and social previews

DEVALAND — Sat, 18 Jul 2026 06:27:40 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

My site (devaland.com) is a static blog built with React and vite-react-ssg, around 70 articles. Every article has a hero image, served as WebP/AVIF for performance. Those articles are also imported into Medium and shared on LinkedIn and X.

Bug Fix or Performance Improvement

A silent bug: WebP/AVIF hero images and og:image tags do not import into Medium's "Import a story" and do not render link previews on LinkedIn or X. The page looks perfect, but importing an article pulled no hero image, and shared links showed no preview. Nothing errors; the image just vanishes.

There is a sneaky second half: even after fixing the og:image, Medium still dropped the hero, because Medium imports the image from the article body <img>, which was also WebP. Two layers, one root cause.

Repro: point a page's hero <img> and og:image at a .webp, then run the URL through Medium's importer or the LinkedIn Post Inspector. No image. Swap to .jpg, it appears.

Code

The repo is private, so here are the exact changes as code snippets.

1) A prebuild step that auto-generates a .jpg twin of every local hero, skip-if-exists:

// scripts/gen-og-jpg.mjs (runs in `prebuild`)
import { blogPosts } from "../src/data/mock.mjs";
import { execFileSync } from "node:child_process";
import fs from "node:fs"; import path from "node:path";
const isLocalRaster = i => i && !/^https?:/i.test(i) && /\.(webp|avif)$/i.test(i);
for (const rel of [...new Set(blogPosts.map(p => p.image).filter(isLocalRaster))]) {
  const src = path.join("public", rel), jpg = src.replace(/\.(webp|avif)$/i, ".jpg");
  if (fs.existsSync(jpg) || !fs.existsSync(src)) continue;
  execFileSync("ffmpeg", ["-y", "-loglevel", "error", "-i", src, "-q:v", "3", jpg]);
}

2) Point both the og:image and the visible body hero <img> at the JPG twin:

ogImage={post.image?.replace(/^(\/.+)\.(webp|avif)$/i, '$1.jpg')}
src={post.image?.replace(/^(\/.+)\.(webp|avif)$/i, '$1.jpg')}

My Improvements

The trick is to keep WebP for the live page (performance) but serve a JPG wherever a scraper or importer looks. The prebuild script runs on every build, so new articles are covered automatically with zero manual work, and the generated JPGs are committed so the deploy does not depend on the CI having ffmpeg. 37 heroes converted. Result: the hero now imports into Medium automatically and every link preview renders, while browsers still get WebP on the page. The boring, permanent kind of fix that clears the bug off the stage for good.