Nobody Is Going to Pay You to Read a PDF
Document extraction is now a commodity API call at $1.50 per 1,000 pages, so the money in your document AI product moved to schema, exceptions, and human review
A founder showed me a quote last year for "document AI." Six figures, nine months, a team of four. The scope document spent eleven pages on OCR accuracy, table detection, and multi-column layout handling, and about a paragraph and a half on what the product actually did with the extracted data.
He asked me whether the price was fair. Wrong question. The price was fair for the thing being built. The thing being built was the wrong thing.
Last week Cohere shipped Parse, a document intelligence model that turns messy multimodal files into structured data across nine languages, priced at $1.50 per 1,000 pages. I haven't used it. I don't need to have used it to tell you what it means, because Google, AWS, Mistral, and half a dozen startups have been marching this price down for two years and this is just the next step on a curve that only goes one direction.
Here is the sentence I want the founder in proptech, legal, insurance, or claims ops to sit with: reading the document is no longer a product.
What I actually spent six months on
I was fractional CTO for an immigration-AI company. On paper, the product was a document pipeline. Clients uploaded a pile of visa paperwork, passports, I-94s, employment letters, degree certificates, tax records, half of it scanned by a phone camera at an angle, and the system pulled out the fields that mattered and assembled a filing.
Extraction was the pitch. Extraction was maybe three weeks of the work.
The other six months went into things nobody puts on a slide. What happens when the model reads a name as "Muhammed" on the passport and "Mohammed" on the employment letter? That is not an extraction bug. That is a real-world discrepancy that an actual immigration attorney needs to see, flag, and resolve, because getting it wrong is not a bad user experience, it is a rejected petition and someone's life on hold for four months.
What happens when the model is 92% sure of a date of birth? Ninety-two percent sounds great in a demo. In a filing, 92% means eight out of a hundred cases go out wrong, and you will not know which eight. So somebody has to decide the threshold. Above it, auto-fill. Below it, route to a human. And that number is not a technical decision, it is a business decision about how much of your margin you are willing to spend on review labor versus how much liability you are willing to eat.
What happens when a required document is simply missing, or is the right document from the wrong year, or is a form the government redesigned in March? None of that is parsing. All of it is product.
The layer that is actually yours
Once anyone can buy extraction for less than the cost of a coffee per thousand pages, the parts of a document product that still have value are the parts that encode what you know.
The first is the domain schema. Not "extract the fields," but knowing which fields exist, which are required in which combinations, which contradict each other, and which are legally load-bearing. A generic parser gives you key-value pairs. Your schema knows that if the employment start date precedes the visa issue date, something is wrong and a human must look at it. That knowledge came out of a lawyer's head, not a model.
The second is exception handling. Every real document workflow is 70% boring and 30% weird, and the 30% is where your product either earns trust or gets abandoned in month two. I have watched teams build beautiful pipelines that handle the clean case perfectly and then dump every anomaly into a Slack channel that becomes a graveyard. Users notice within a week.
The third is the review interface. This is the one founders underinvest in most, and it is the one I would spend the money on first. When the model is uncertain, someone has to look. How fast can they look? Can they see the original document region next to the extracted value, highlighted, without scrolling? Can they correct it in one keystroke? Does the correction teach the system anything, or does the same mistake come back next Tuesday?
Reviewer throughput is your unit economics. If a paralegal can clear 40 documents an hour instead of 12, you have a business. That gap lives entirely in the interface, not the model.
What to do with the budget
If you are about to fund an extraction pipeline, stop and re-cut the scope.
Buy the parse. Treat it as a vendor line item, the way you treat Stripe or Twilio. Assume the price falls again next year and the quality goes up, and build so you can swap providers in an afternoon rather than a quarter. Do not let anyone on your team fine-tune a document model for your first version. You will spend three months matching something you could have rented.
Then spend the real money above it. Sit with the two or three people who currently do this work by hand and write down every judgment call they make. That document is your product spec. The confidence thresholds, the escalation rules, the "when in doubt, ask a human this specific question" logic. That is the asset.
And ship the human review flow in version one, not version three. Every founder I have met in this space plans to add review "once accuracy improves." Accuracy never improves enough to remove the human, it only improves enough to make the human faster. Design for a person in the loop from day one and your accuracy problem becomes a throughput problem, which is a much nicer problem.
The honest counter-argument: in a narrow enough domain with clean enough inputs, you can get to full automation, and then extraction quality genuinely is the moat. I have seen it work exactly once, with a client whose input was a single machine-generated form type. If your documents come from phone cameras and different countries and forms that change annually, that is not you.
The scoping conversation for this is short. Usually one or two sessions to figure out which parts of your pipeline are now a line item and which parts deserve your MVP budget. That is most of what a two-week fractional CTO sprint is for, and it is $4,500, which is considerably cheaper than nine months of building something you can now rent.
Nobody is going to pay you to read a PDF. They will pay you to be right about what is in it, and to know when you are not.