[HN Gopher] Launch HN: Extend (YC W23) - Turn your messiest docu...
___________________________________________________________________
Launch HN: Extend (YC W23) - Turn your messiest documents into data
Hey HN! We're Kushal and Eli, co-founders of Extend
(https://www.extend.ai/). Extend is a toolkit for AI teams to
ingest any kind of messy document (e.g. PDFs, images, excel files)
and build incredible products. We built Extend to handle the
hardest documents that break most pipelines. You can see some
examples here in our demo (no signup required):
https://dashboard.extend.ai/demo I know you're probably thinking
"not another document API startup". Unfortunately, the problem just
isn't solved yet! I've personally spent months struggling to build
reliable document pipelines at a previous job. The long tail of
edge cases is endless -- massive tables split across pages, 100pg+
files, messy handwriting, scribbled signatures, checkboxes
represented in 10 different formats, multiple file types... the
list just keeps going. After seeing countless other teams during
our time in YC run into these same issues, we started building
Extend. We initially launched with a set of APIs for engineers to
parse, classify, split, and extract documents. That started to take
off, and soon we were deployed in production at companies building
everything from medical agents, to real-time bank account
onboarding, to mortgage automation. Over time, we've worked closely
with these teams and seen first-hand how large the gap is between
raw OCR/model outputs --> a production-ready pipeline (LLMs and
VLMs aren't magic). Unlike other solutions in the space, we're
specifically focused on three core areas: (1) the computer vision
layer, (2) LLM context engineering, and (3) the surrounding product
tooling. The combination of all three is what we think it takes to
hit 99% accuracy and maintain it at scale. For instance, to parse
messy handwriting, we built an agentic OCR correction layer which
uses a VLM to review and make edits to low confidence OCR errors.
To tackle multi-page tabular data, we built a semantic chunking
engine which can detect the optimal boundaries within a document so
models can excel with smaller context inputs. We also shipped a
prompt optimization agent to automate the endless prompt
engineering whack-a-mole teams spend time on. It's built as a
background agent to replicate the best prompter on your team, and
runs in a loop with access to a set of tools (view files, run
evals, analyze results, and update schemas). The most surprising
part of this whole experience has been seeing how many crazy PDF
formats are out there! We've run into everything from supermarket
inventory magazines, pesticide labels, construction blueprints, and
satellite manufacturing plans. Everything described above is live
today. You can see it in action here (no signup):
https://dashboard.extend.ai/demo. To upload your own files, you can
log in and do so (we're adding free usage credits to all accounts
that sign up today). We're excited to be sharing with HN! We'd
love to hear about your experiences building document pipelines.
Please try it out, and share any and all feedback with us (e.g.
hard documents that didn't work, feature requests).
Author : kbyatnal
Score : 42 points
Date : 2025-10-09 16:06 UTC (6 hours ago)
(HTM) web link (www.extend.ai)
(TXT) w3m dump (www.extend.ai)
| FabioFleitas wrote:
| We've been using Extend for over a year and have been super happy
| with the product and accuracy of the data extraction
| kbyatnal wrote:
| thank you Fabio!
| nextworddev wrote:
| Just how many IDP / document processing "AI" startups are out
| there?
| kbyatnal wrote:
| There's definitely no shortage of options. OCR has been around
| for decades at this point, and legacy IDP solutions really
| proliferated in the last ~10 years.
|
| The world today is quite different though. In the last 24
| months, the "TAM" for document processing has expanded by
| multiple orders of magnitude. In the next 10 years, trillions
| of pages of documents will be ingested across all verticals.
|
| Previous generations of tools were always limited to the same
| set of structured/semi-structured documents (e.g. tax forms).
| Today, engineering teams are ingesting truly the wild west of
| documents, from 500pg mortgage packages to extremely messy
| healthcare forms. All of those legacy providers fall apart when
| tackling these types of actual unstructured docs.
|
| We work with hundreds of customers now, and I'd estimate 90% of
| the use cases we tackle weren't technically solvable until ~12
| months ago. So it's nearly all greenfield work, and very rarely
| replacing an existing vendor or solution already in place.
|
| All that to say, the market is absolutely huge. I do suspect
| we'll see a plateau in new entrants though (and probably some
| consolidation of current ones). With how fast the AI space
| moves, it's nearly impossible to compete if you enter a market
| just a few months too late.
| nextworddev wrote:
| fully aware that OcR and IDP has been around, but the "AI
| native" versions are pretty saturated too
| kbyatnal wrote:
| There's certainly a lot of tools that focus on individual
| parts of the problem (e.g. the OCR layer, or workflows on
| top). But very few that solve the problem end-to-end with
| enough flexibility for AI teams that want a lot of control
| over the experience.
|
| For example, we expose options for AI teams to control how
| chunking works, whether to enable a bounding box citation
| model, and whether a VLM should correct handwriting errors.
|
| Most customers we speak with, the evaluation is actually
| between Extend or building it in-house (and we have a
| pretty good win rate here).
| nextworddev wrote:
| Not sure about that. There's Llamaindex and plus many
| other document orchestration frameworks
| airstrike wrote:
| Congrats on the launch! It looks really cool.
|
| _> Unlike other solutions in the space, we 're specifically
| focused on three core areas: (1) the computer vision layer, (2)
| LLM context engineering, and (3) the surrounding product
| tooling._
|
| I assume the goal is to continue to serve this via an API? That
| would be immensely helpful to teams building other products
| around these capabilities.
| kbyatnal wrote:
| thanks! Yup that's correct, we offer a set of APIs for handling
| documents: parsing, classification, splitting, and extraction.
|
| We've seen customers integrate these in a few interesting ways
| so far:
|
| 1. Agents (exposing these APIs as tools in certain cases, or
| into a vector DB for RAG)
|
| 2. Real-time experiences in their product (e.g. we power all of
| Brex's user-facing document upload flows)
|
| 3. Embedded in internal tooling for back-office automation
|
| Our customers are already requesting new APIs and capabilities
| for all the other problems they run into with documents (e.g.
| fintech customers want fraud detection, healthcare users need
| form filling). Some of these we'll be rolling out soon!
| wunderlust wrote:
| For some reason "turn your messiest data into documents" makes
| more sense.
| airstrike wrote:
| Seconded. It's unstructured data that becomes structured.
| nibab wrote:
| at ng3n.ai ive been using datalab.to for document processing.
| currently its mostly for conversion to markdown and some
| extraction.
|
| ng3n is more of a grid-like workflow solution on top of
| documents. it's a user-facing application geared towards non-
| technical users that have processing needs.
|
| if there are all these new problems that became solvable, what
| exactly are they?
|
| id be interested in replacing datalab with extend, but im not
| sure what avenues that opens for ng3n. would be very curious to
| learn!
| kbyatnal wrote:
| thanks! Datalab is great, I've met Vik a few times and their
| team has done some impressive work. We can also support the
| conversion to markdown use case, and might be a better fit
| depending on your use case. Feel free to create an account to
| try it out!
| FitchApps wrote:
| Very cool. Are there any checks for accuracy / data verification?
| How accurate is your solution when it comes to messy table
| parsing or handwriting.
| kbyatnal wrote:
| thanks!
|
| A lot of customers choose us for our handwriting, checkbox, and
| table performance. To handle complex handwriting, we've built
| an agentic OCR correction layer which uses a VLM to review and
| make edits to low confidence OCR errors.
|
| Tables are a tricky beast, and the long tail of edge cases here
| is immense. A few things we've found to be really impactful are
| (1) semantic chunking that detects table boundaries (so a table
| that spans multiple pages doesn't get chopped in half) and (2)
| table-to-HTML conversion (in addition to markdown). Markdown is
| great at representing most simple tables, but can't represent
| cases where you have e.g. nested cells.
|
| You can see examples of both in our demo!
| https://dashboard.extend.ai/demo
|
| Accuracy and data verification is challenging. We have a set of
| internal benchmarks we use, which gets us pretty far, but
| that's not always representative of specific customer
| situations. That's why one of the earliest things we built was
| a evaluation product, so that customers can easily measure
| performance on their exact docs and use cases. We recently
| added support for LLM-as-a-judge and semantic similarity
| checks, which have been really impactful for measuring accuracy
| before going live.
| aaa29292 wrote:
| on the pricing page, what in the world is performance optimized
| vs cost optimized???
|
| https://docs.extend.ai/2025-04-21/product/general/how-credit...
|
| Are those just different SLAs or different APIs or what?
| aaa29292 wrote:
| How different are the extraction qualities, any benchmarks or
| other info you can share?
| kbyatnal wrote:
| It's very dependent on the use case. That's why we offer a
| native evals experience in the product, so you can directly
| measure the % accuracy diffs between the two modes for your
| exact docs.
|
| As a rule of thumb, light processing mode is great for (1)
| most classification tasks, (2) splitting on smaller docs, (3)
| extraction on simpler documents, or (4) latency sensitive use
| cases.
| serjester wrote:
| This is the most confusing pricing page I've ever seen -
| different options have different credit usage and different
| cost per credits? How many degrees of freedom do you real need
| to represent API cost.
| cle wrote:
| > How many degrees of freedom do you real need to represent
| API cost.
|
| The amount that your users care about.
|
| At a large enough scale, users will care about the cost
| differences between extraction and classification (very
| different!) and finding the right spot on the accuracy-
| latency curve for their use case.
| kbyatnal wrote:
| Exactly correct! We've had users migrate over from other
| providers because our granular pricing enabled new use
| cases that weren't feasible to do before.
|
| One interesting thing we've learned is, most production
| pipelines often end up using a combination of the two (e.g.
| cheap classification and splitting, paired with performance
| extraction).
| kbyatnal wrote:
| Feedback heard. Pricing is hard, and we've iterated on this
| multiple times so far.
|
| Our goal is to provide customers with as much transparency &
| flexibility as possible. Our pricing has 2 axes:
|
| - the complexity of the task
|
| - performance processing vs cost-optimized processing
|
| Complexity matters because e.g. classification is much easier
| than extraction, and as such it should be cheaper. That
| unlocks a wide range of use cases, such as tagging and
| filtering pipelines.
|
| Toggles for performance is also important because not all use
| cases are created equal. Similar to how having options
| between cheaper and the best foundation models is important,
| the same applies to document tasks.
|
| For certain use cases, you might be willing to take a slight
| hit to accuracy in exchange for better costs and latency. To
| support this, we offer a "light" processing mode (with
| significantly lower prices) that uses smaller models, fewer
| VLMs, and more heuristics under the hood.
|
| For other use cases, you simply want the highest accuracy
| possible. Our "performance" processing mode is a great fit
| for that, which enables layout models, signature detection,
| handwriting VLMs, and the most performant foundation models.
|
| In fact, most pipelines we seen in production often end up
| combining the two (cheap classification and splitting, paired
| with performance extraction).
|
| Without this level of granularity, we'd either be
| overcharging certain customers or undercharging others. I
| definitely understand how this is confusing though, we'll
| work on making our docs better!
| kbyatnal wrote:
| good question!
|
| Our goal is to provide customers with as much flexibility as
| possible. For certain use cases, you might be willing to take a
| slight hit to accuracy in exchange for better costs and
| latency. To support this, we offer a "light" processing mode
| (with significantly lower prices) that uses smaller models,
| fewer VLMs, and more heuristics under the hood.
|
| For other use cases, you simply want the highest accuracy
| possible. Our "performance" processing mode is a great fit for
| that, which enables layout models, signature detection,
| handwriting VLMs, and the most performant foundation models.
|
| We back this up with a native evals experience in the product,
| so you can directly measure the % accuracy difference between
| the two modes for your exact use case.
| asdev wrote:
| Have you ran your pipeline against an open benchmark like
| https://github.com/opendatalab/OmniDocBench?
___________________________________________________________________
(page generated 2025-10-09 23:00 UTC)