Most active commenters
  • maxmaio(3)
  • tlofreso(3)

←back to thread

59 points maxmaio | 14 comments | | HN request time: 0.637s | source | bottom

Hey HN, we are Max, Kieran, and Aahel from Midship (https://midship.ai). Midship makes it easy to extract data from unstructured documents like pdfs and images.

Here’s a video showing it in action: https://www.loom.com/share/ae43b6abfcc24e5b82c87104339f2625?..., and a demo playground (no signup required!) to test it out: https://app.midship.ai/demo

We started 5 months ago initially trying to make an AI natural language workflow builder that would be a simpler alternative to Zapier or Make.com. However, most of our users seemed to be much more interested in the basic (and not very good) document extraction feature we had. Seeing how people were spending hours a day manually extracting data from pdfs inspired us to build what has become Midship!

The problem is that despite all our progress in software, huge amounts of business data still lives in PDFs and images. Sure, you can OCR them, but getting clean, structured data out is still painful. Most existing tools just give you a blob of markdown - leaving you to figure out which parts matter and how they relate.

We've found that combining OCR with language models lets us do something more useful: extract specific fields and tables that users actually care about. The LLMs help correct OCR mistakes and understand context (like knowing that "Inv#" and "Invoice Number" mean the same thing).

We have two main kinds of users today, non-technical users that extract data via our web app and developers who use our extraction api. We were initially focused on the first one as they seemed like an underserved part of the market, but we’ve received a lot of interest from developers who face the same issues.

For pricing, we currently charge a monthly Saas fee per seat for the web app and a volume based pricing for the API.

We’re really excited to share what we’ve built so far and look forward to any feedback from the community!

1. hubraumhugo ◴[] No.42067242[source]
Congrats on the launch! A quick search in the YC startup directory brought up 5-10 companies doing pretty much the same thing:

- https://www.ycombinator.com/companies/tableflow

- https://www.ycombinator.com/companies/reducto

- https://www.ycombinator.com/companies/mindee

- https://www.ycombinator.com/companies/omniai

- https://www.ycombinator.com/companies/trellis

At the same time, accurate document extraction is becoming a commodity with powerful VLMs. Are you planning to focus on a specific industry, or how do you plan to differentiate?

replies(7): >>42067424 #>>42067521 #>>42067529 #>>42067560 #>>42067808 #>>42068776 #>>42071352 #
2. maxmaio ◴[] No.42067424[source]
Yes there is definitely a boom in document related startups. We see our niche as focusing on non technical users. We have focused on making it easy to build schemas, an audit and review experience, and integrating into downstream applications.
3. ◴[] No.42067521[source]
4. ◴[] No.42067529[source]
5. tlofreso ◴[] No.42067560[source]
"accurate document extraction is becoming a commodity with powerful VLMs"

Agree.

The capability is fairly trivial for orgs with decent technical talent. The tech / processes all look similar:

User uploads file --> Azure prebuilt-layout returns .MD --> prompt + .MD + schema set to LLM --> JSON returned. Do whatever you want with it.

replies(2): >>42068181 #>>42069425 #
6. mitchpatin ◴[] No.42067808[source]
TableFlow co-founder here - I don't want to distract from the Midship launch (congrats!) but did want to add my 2 cents.

We see a ton of industries/use-cases still bogged down by manual workflows that start with data extraction. These are often large companies throwing many people at the issue ($$). The vast majority of these companies lack technical teams required to leverage VLMs directly (or at least the desire to manage their own software). There’s a ton of room for tailored solutions here, and I don't think it's a winner-take-all space.

replies(1): >>42067996 #
7. maxmaio ◴[] No.42067996[source]
+1 to what mitch said. We believe there is a large market for non-technical users who can now automate extraction tasks but do not know how to interact with apis. Midship is another option for them that requires 0 programming!
8. kietay ◴[] No.42068181[source]
Totally agree that this is becoming the standard "reference architecture" for this kind of pipeline. The only thing that complicates this a lot today is complex inputs. For simple 1-2 page PDFs what you describes works quite well out of the box but for 100+ page doc it starts to fall over in ways I described in another comment.
replies(1): >>42068732 #
9. tlofreso ◴[] No.42068732{3}[source]
Are really large inputs solved at midship? If so, I'd consider that a differentiator (at least today). The demo's limited to 15pgs, and I don't see any marketing around long-context or complex inputs on the site.

I suspect this problem gets solved in the next iteration or two of commodity models. In the meantime, being smart about how the context gets divvied works ok.

I do like the UI you appear to have for citing information. Drawing the polygons around the data, and then where they appear in the PDF. Nice.

10. erulabs ◴[] No.42068776[source]
Execution is everything. Not to drop a link in someone else’s HN launch but I’m building https://therapy-forms.com and these guys are way ahead of me on UI, polish, and probably overall quality. I do think there’s plenty of slightly different niches here, but even if there were not, execution is everything. Heck it’s likely I’ll wind up as a midship customer, my spare time to fiddle with OCR models is desperately limited and all I want to do is sell to clinics.
replies(1): >>42072611 #
11. Kiro ◴[] No.42069425[source]
Why all those steps? Why not just file + prompt to JSON directly?
replies(1): >>42070089 #
12. tlofreso ◴[] No.42070089{3}[source]
Having the text (for now) is still pretty important for quality output. The vision models are quite good, but not a replacement for a quality OCR step. A combination of Text + Vision is compelling too.
13. hermitcrab ◴[] No.42071352[source]
Do you know if there any good (pref C++) libraries for extracting data tables from PDFs?
14. _hfqa ◴[] No.42072611[source]
Just a heads up, but I tried to signup but the button doesn't seem to work.