I spent weeks building a PDF workflow. Now I need strangers to break it.
I’ve been building a small product called PDflow.
The original idea was simple:
Turn messy PDF tables into usable Excel files.
I thought the hard part would be extraction.
It wasn’t.
One real-world document extracted most of the text correctly, but the spreadsheet exploded into around 20 columns because the structure was reconstructed badly.
That was the moment I realized:
PDF → Excel is not just an extraction problem. It’s a reconstruction problem.
The beta is live now, but the bigger question I’m trying to answer is not technical:
Who actually needs this badly enough to use it?
I’m looking for the first 30 people who regularly deal with:
PDF tables
reports
forms
invoices
messy business documents
files that technically convert, but still require manual Excel cleanup
What I want to learn:
How often does this problem happen?
What kinds of PDFs cause the most pain?
Is the recovered spreadsheet actually usable?
Is this painful enough that someone would pay to solve it?
I’m especially interested in difficult, sanitized, non-sensitive PDFs.
The uglier the file, the better 😂
This is still a real beta, not a polished launch.
If you’ve dealt with this problem before, I’d love to hear how you solve it today.
You need to test the reconstruction process rigorously.
I've built messy pdf data extraction pipeline into csv before.
It wasn't that easy. But i think there are folks out there who would love to pay for this feature to process ton of pdfs into excel.
Yeah, that’s exactly what I’m realizing. Extraction is only the first half — reconstruction is where things get messy fast.
I’m testing now whether the real value is less “PDF → Excel” and more “get to a spreadsheet you can actually trust and use without 30–40 minutes of cleanup.”
I’m also curious: when you built your pipeline, what kind of PDF broke it most often?
Your first 30 will probably come from people who already have a recurring spreadsheet-cleanup step. I’d recruit through communities where that workflow is discussed, ask for a sanitized before/after pair, and make the test about minutes saved rather than whether the extraction looks impressive. A second upload is usually a stronger signal than a compliment.
I agree. I’m starting to think “minutes saved before the spreadsheet becomes usable” is a much better metric than whether the extraction looks impressive.
And yes, second upload is becoming one of the signals I care about most. The first file might be curiosity; the second usually means the workflow is real.
I’m also trying to collect sanitized before/after pairs now so I can measure cleanup more concretely.
In my experience building compliance and reporting tools, messy tables are an absolute headache. The hardest part is rarely the clean rows; it is multi-page splits, merged subtotal lines, and subtle layout shifts between monthly statements. In my case, users would rather have the tool flag an ambiguous row than silently guess and blow up the column structure. Getting people to pay usually comes down to whether your reconstruction saves them from manually retyping audit totals.
This is very close to what I’ve been seeing too.
The clean rows usually aren’t the real problem — it’s the merged subtotals, repeated structures, and small layout shifts that suddenly break reconstruction.
I also agree with your point about ambiguity. I’d much rather surface “this row is uncertain” than silently force it into the wrong column and make the spreadsheet look trustworthy when it isn’t.
The part I’m still trying to validate is exactly what you mentioned: whether that reduction in retyping and verification work is large enough, and frequent enough, to justify paying for.
In your compliance/reporting workflows, what usually costs more time: fixing the reconstructed structure, or verifying that totals and key fields are still correct?
The useful measure of success probably isn't "text extracted correctly." It's whether someone can do the next job without rebuilding the sheet. Give testers a real follow-up task, such as filtering invoices by client or totaling a column. Then measure how long they spend cleaning the data before they can begin. That will tell you more than a general quality score, especially when a table looks right but its columns have shifted.
This is a really useful distinction.
I like the idea of measuring whether the output is actually usable for the next task, not just whether the extracted text looks correct.
“Time before you can start the real job” might be a much better metric than a generic quality score.
I’m going to add a simple follow-up task to the beta tests and track cleanup time before the user can actually work with the sheet.
Thanks — this gives me a much more concrete way to measure usability.
The extraction vs. reconstruction distinction is really interesting. I’d be curious to see whether users care more about raw accuracy or simply how much manual cleanup they have to do after the conversion.
Your own post has the targeting in it: "files that technically convert, but still require manual Excel cleanup". That's not a type of document. That's someone having a specific bad afternoon. They already tried the free converter, got something that opened in Excel, and then spent forty minutes fixing merged cells.
That’s a really useful distinction.
“Files that technically convert but still need cleanup” is more of a workflow problem than a document type. I’ve probably been thinking too much in terms of PDFs and not enough in terms of the person who keeps having this bad afternoon repeatedly.
I’m going to pay more attention to recurring cleanup workflows first, then see which document families actually show up.
Building on the "flag uncertain rows" idea above: for the compliance/financial use case JasonHuangAE86 mentioned, I'd go one step further than flagging — let the user click any cell in the output and jump straight to the exact region it came from in the source PDF. Verification is usually the actual time sink, not the flag itself; people don't just want to know a row is uncertain, they want to check it against the original in a few seconds instead of hunting through a 40-page PDF. That traceability might be what turns "cleanup avoided" into "verification avoided" as your value metric — and the second one is arguably easier to defend as a paid feature.
I really like this. The jump-back-to-source idea feels much closer to the actual verification problem than just showing a warning badge.
If someone can click a suspicious cell and immediately see where it came from in the PDF, that could reduce the “hunt through 40 pages” part of the job.
I’m not building that into the current test yet, but I’m definitely keeping it as a next-stage product hypothesis.
Makes sense to keep it as a later-stage hypothesis rather than scope creep on the current test. Good luck with the launch — curious to see what the strangers end up breaking first.
Exactly 😄. I’ve probably learned enough from my own test files for now. Time to let strangers break it and see which failures actually repeat.
Right now my 'solution' is a mess of custom Python scripts followed by 10 minutes of manually deleting blank columns in Excel. It sucks. I’ve actually got a few ugly, multi-page financial reports (sanitized) with mixed table formats that crash pretty much every free converter out there.
This is exactly the kind of real-world case I’m looking for.
The fact that you already have custom scripts and still spend time cleaning blank columns afterward is especially interesting.
If those reports are already sanitized, I’d genuinely love to test one or two of them with PDflow and compare the result against your current workflow.
I’m much more interested in where it fails and how much cleanup is still needed than in getting a “perfect demo.”
If you’re open to it, I can send you the beta link.
Happy to help break edge cases if useful. For PDF pipelines I would specifically try weird page sizes, password-protected files, scanned image-only PDFs, and concurrent uploads. Those four usually surface the painful failure modes faster than happy-path demos. SAO-W2-PDF
Wrestling with the same willingness-to-pay question. What worked for me: free for one group, $8/mo Pro — the free tier gets whole groups in the door and the upgrade moment is obvious. For your 30 testers, I'd watch for anyone processing a PDF they'd otherwise pay someone to handle — that's the "would pay" signal.
One thing that would help you score reconstruction: ask each tester for the ugly PDF and also the spreadsheet they ended up with after cleaning it by hand. That pair is your ground truth. Then you can measure how many cells your output gets right against what a person actually needed, instead of guessing whether 20 columns is wrong or just unusual. It also shows you which fixes people make every single time, which is probably the part they would pay for.
I really like this framing.
Using the spreadsheet they actually ended up with as ground truth removes a lot of guesswork about what “correct” means.
I’m going to start collecting that pair whenever possible:
ugly PDF → human-cleaned spreadsheet → PDflow output
Then I can measure both reconstruction accuracy and, probably more importantly, how much manual correction PDflow actually removes.
That feels much closer to a real product metric than extraction accuracy alone.
Hey! I came across your post about your product and really liked what you're building.
I’m a UI/UX designer specializing in SaaS products and high-converting website/landing page design in Figma.
I had a couple of ideas for improving the product’s landing-page presentation and making the value proposition clearer for new visitors.
If you’re open to it, I’d be happy to share a few quick ideas. 🚀
Your strongest buying signal may be the second upload, not the first export. A user who brings another document from the same recurring workflow has shown both pain and repeatability. I would instrument time from upload to accepted spreadsheet, number of cells or rows manually corrected, and whether the same template returns. That gives you a defensible “minutes of cleanup avoided” metric instead of extraction accuracy alone.
“The second upload, not the first export” is a really useful distinction.
A first upload can just be curiosity. A second document from the same workflow is much stronger evidence that the problem actually repeats.
I also like “minutes of cleanup avoided” as the metric. I’m starting to think that may be more commercially meaningful than raw extraction accuracy.
I’m going to track:
repeat upload
time to accepted spreadsheet
manual corrections after export
whether the same document family returns
Thanks — this sharpens the beta considerably.
The “need strangers to break it” stage is underrated.
Especially with a workflow product, I’d be looking less for people to tell you whether they like it and more for the exact point where they stop understanding what to do next.
If you’re still looking for testers, happy to take a look from a product/UX perspective.
The 'I thought extraction was the hard part, turns out reconstruction was' moment is real. I hit something similar building my own thing this month. I kept assuming one specific feature would be the hardest part to get right, then a completely unrelated bug ended up eating way more time than the thing I was actually worried about. You never really know where the real difficulty is until you're inside it.
On your actual question though, who needs this badly enough to pay, that's the exact thing I've been trying to figure out too. What's worked better for me than asking people directly is watching what they actually do once they try it, not what they say they'd pay for. Are you planning to track usage from your first 30, or going mostly off what they tell you?
That’s exactly where I want to go next.
I don’t want to rely mainly on “would you pay for this?” answers because I know those are cheap signals.
For the first 30, I want to track actual behavior:
what document they upload
whether they reach the recovered table
whether they export Excel
whether they come back with another file
whether they still need manual cleanup afterward
I’m especially interested in repeated use and cleanup time, because those feel closer to real value than stated willingness to pay.
I’m still deciding how much instrumentation to add before the beta gets too heavy, but yes — behavior over opinions is the goal.
If you’ve done this before, which behavior ended up being the strongest buying signal for you?
The reconstruction problem seems more commercially important than raw extraction accuracy. Have early users shown that fixing the resulting spreadsheet takes enough time to justify paying for PDflow, or is proving that cleanup burden still the main unknown?
That’s still the main unknown.
I have evidence that reconstruction failures create real cleanup work, but I don’t yet have enough evidence that the time saved is large or frequent enough to justify paying.
That’s why I’m trying to get the first real users before adding more features.
What I want to measure next is:
how often this cleanup happens
how long it usually takes
whether the same document pattern repeats
whether people already pay for tools or manual help to deal with it
If the cleanup burden is occasional and low-cost, then the product probably isn’t commercially interesting.
If it’s recurring and tied to a workflow people already spend money or labor on, that’s a very different signal.
That recurring cleanup-cost question is the right commercial test. If you’re open to it, what’s the best email to reach you on?
Absolutely — you can reach me at lyx.19865598248@gmail.com.
Would be happy to continue the conversation. I’m especially interested in your perspective on recurring cleanup cost and what would make this commercially meaningful rather than just technically useful.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
The useful split here is extraction versus reconstruction. For a public beta I’d test a small “nasty corpus” before polishing the happy path: merged cells, repeated headers, blank spacer rows, mixed date/locale formats, subtotals, and PDFs with the same visual layout but different column order. I’d also show a confidence flag or a quick review queue for rows that don’t map cleanly—trust tends to come from making the uncertain cases obvious, not pretending every conversion is perfect.
I strongly agree with this.
The “nasty corpus” idea is close to how I’m thinking about the next phase.
I’ve already been separating source fidelity from usable reconstruction, and I don’t want the product to pretend every conversion is equally trustworthy.
A lightweight review layer for uncertain rows/cells is probably more valuable than chasing perfect extraction everywhere.
The hard part is deciding what to surface as uncertain without creating too much review burden.
I’m especially interested in:
merged cells
repeated headers
sparse forms
locale/number format differences
structurally similar documents with shifted columns
I think the real target is not “100% correct conversion”, but “make the risky parts obvious and cheap to fix before export.”