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.
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 '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.
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.”