Comparison

Densery vs building it in-house

This is the option that wins most of these meetings, and it deserves a straight answer rather than fear. Open-weight document models are genuinely good and genuinely free, they run on your own GPUs, and your platform team is right that the extraction problem is largely solved. The disagreement is about which part of the work is hard.

Work out your own number See the evidence layer

building it in-house

Your own team, open models, your own hardware

COMPARED ON

Densery

A process delivered working

	building it in-house	Densery
Extraction	Open-weight models read complex documents locally for cents per thousand pages. Your team can stand this up in weeks. They are right about this.	We buy the same layer, including the same open-weight models. We do not claim an advantage here and do not charge for one.
The ontology	Has to be elicited from your specialists and written down — what makes a file complete, which mismatch is material, which exception gets asked about. This is 12–24 months of work and it is nobody's day job.	Already built and running for banking, insurance, manufacturing and telecom. Extended with your specifics during implementation rather than started from zero.
Write-back into the system of record	Achievable, and where scope quietly triples. Every core, LOS, claims and quality system has its own permissions, service accounts and failure modes.	Through your existing APIs under your existing service identities. Where a legacy system has no API, we operate it the way your staff do, under a named identity with every action logged.
The evidence layer	Almost always deferred to phase two, and phase two is where the project dies. Per-decision provenance is harder to retrofit than to build in.	The reason the other three layers are deployable at all. Built first, not last.
Cost	Free at the margin and politically favoured. The real cost is your best ML engineers not doing something differentiating.	A line item, visible, and easy to cancel. That visibility cuts both ways and we know it.
Odds	MIT NANDA: purchased solutions reach production roughly twice as often as internal builds. 88% of agent pilots never make it.	Six deployments in production. Not a large number — but they are in production, in supervised institutions, and you can call them.
When it clearly wins	You have 30+ ML engineers and document work is core to your product rather than a cost of running it.	We disqualify those accounts ourselves. If that is you, we are not going to win and should not.

Statements about building it in-house are drawn from their public website and published materials as at 15 August 2026 and are our reading of them, not their words. Product capability changes; check anything here that matters to your decision, and tell us if we have it wrong.

When you should buy building it in-house.

Written straight, because you will find this out anyway and it costs us less to say it now.

You have thirty or more ML engineers and can dedicate a team, not a rotation, for four quarters.
Document understanding is part of what you sell, not part of what you spend.
Your estate is one document type, clean, digital and stable, and the rules rarely change.
You have already built a governed agent in production somewhere else in the business and know exactly what it cost.
A vendor contract is genuinely harder for you to get through than a headcount request.

When Densery is the better answer.

Narrower than the list on the left, deliberately.

Your ML capacity is under ten people and already fully committed to something the business considers strategic.
You need this working in a quarter, not in eighteen months.
A previous internal attempt reached a demo and stalled before production. This is the single most common reason people call us.
The ontology work would require your best specialists to stop reviewing files in order to describe how they review files.
You want somebody contractually accountable when the output is wrong.

The honest verdict

We win this comparison less often than the other three, and when we lose it we usually deserve to. A team that has already shipped a governed agent into production does not need us.

But the honest version includes the base rate. Internal builds in this category fail at a high rate, and they fail late — typically after twelve to eighteen months, at the point where the evidence and governance layer turns out to be the whole problem rather than a finishing task. The extraction demo works in week three, which is exactly what makes the timeline feel achievable.

The question worth putting to your own team is not "can we build this" — they can, and telling them otherwise is insulting. It is: who writes down the ontology, when does the audit record get built, and what else stops while that happens? If those three have clean answers, build it. We mean that.

Two ways to test this without talking to us

Both are ungated and neither asks for an email. Run your own volume through the calculator, then open a real file in the audit-trail explorer and click the fields that failed.

Value calculator Audit-trail explorer

The next step

Ninety minutes, your documents, three numbers.

A scoping session is not a demo. Bring twenty real files, redacted if you need to. We take three numbers off you — annual volume, fully loaded cost per file today, and what happens when the output is wrong — and hand back a one-page value case in your own KPIs.

If the arithmetic says we are not a fit, we will tell you in the room rather than six weeks later.

Book a scoping session Work out the number first

QUALIFY YOURSELF OUT

We are a fit if all three are true

More than 250,000 pages a year, or 25,000 claims or files
A legal obligation — regulator, board risk committee or parent-company policy — to keep the data in-house
An AI or agent pilot that did not reach production

If your data can go anywhere and your documents are already clean and digital, you do not need us. Use a hyperscaler document API and spend the money on something harder.