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.
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
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.
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.
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?
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.
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 “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?
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.”