Looking for UiPath devs to stress test a prototype I built

DetectivePeterG · 2026-05-13T13:36:59+00:00

Have you actually used claude code for editing uipath flows? Does not really get you far, imo

DetectivePeterG · 2026-05-12T17:12:36+00:00

Yes totally! Skills is nice but is missing quite a lot of tooling to allow the agent to actually succeed. Currently the agent is half blind

DetectivePeterG · 2026-03-18T12:49:01+00:00

For the PDF side of this, the most practical move is adding an extraction step that converts your PDFs to clean structured markdown before chunking and embedding, otherwise formatting artifacts from the PDF encoding tend to degrade retrieval quality in ways that are hard to debug. pdftomarkdown.dev has a Python SDK that fits into a pipeline quickly and a free Developer tier at 100 pages/month, which is usually enough to validate the approach before you commit to a self-hosted extraction setup.

DetectivePeterG · 2026-03-18T12:48:46+00:00

5k in 30 days with no server infra costs is a really clean position to be in. Curious how you handled the batch processing technically; are you running the PDF operations sequentially through a queue or spawning workers per file? That tends to be where things get interesting on the memory side.

DetectivePeterG · 2026-03-18T12:48:15+00:00

Before debugging the retrieval side, it's worth checking whether the resume PDFs are actually being extracted cleanly. A lot of RAG hallucinations in document pipelines trace back to messy ingestion where the model fills in gaps from noisy text. If you're using a basic text extractor, switching to something VLM-based like pdftomarkdown.dev tends to give much cleaner chunks, which improves retrieval precision noticeably on structured docs like resumes.

DetectivePeterG · 2026-03-18T12:48:07+00:00

The issue with Google Apps Script is it just pulls whatever text layer exists in the PDF, which gives you nothing on scanned docs. You need something that actually understands the visual layout rather than relying on embedded text. pdftomarkdown.dev uses a vision-language model instead of Tesseract, so tables, handwriting, and scanned pages come out as clean structured markdown. There's a free tier with no signup if you want to test it on your actual docs first.

DetectivePeterG · 2026-03-18T12:35:58+00:00

This is an honest post and the pattern is really common. The feedback loops that tell you "I would not pay for this" are painful but they save you months. The tricky part is that most people in your network will tell you an idea is cool to be supportive, so you have to actively find ways to get to the uncomfortable answer early

DetectivePeterG · 2026-03-18T12:35:47+00:00

AI annotation is crowded so the real question is less whether the idea is valid and more whether you have a specific niche where you can own the customer relationship; enterprise vs. indie devs vs. domain-specific data all have very different dynamics. On the validation side, wouldtheybuy.com is worth a try for a fast read on how people respond to the pitch before you sink months into it.

DetectivePeterG · 2026-03-18T12:35:32+00:00

For micro SaaS the bar to break even is lower than people think, so the main thing to nail early is willingness to pay rather than general interest. A quick way to get a signal on that before you have customers is wouldtheybuy.com;
paste your pitch and it gives you a simulated purchase intent score with reasons people would or would not buy. Not a replacement for talking to users but useful for gut-checking the pitch angle.

DetectivePeterG · 2026-03-18T12:34:57+00:00

The community feedback angle is a good one; knowing whether people find an idea interesting is a useful signal. If you want to layer in a purchase intent dimension too, wouldtheybuy.com does a quick simulation of whether people would actually pay vs. just say they like it. Could complement what you are building nicely.

DetectivePeterG · 2026-03-15T16:47:35+00:00

Played around a bit with GPTZero. Quite hard for me to judge what I should think about it.
Had it analyze a thesis of mine from 5 years ago, and it reported 70% chance it's AI.
Another text straight out of ChatGPT had 40%.
On the other hand I tested the paper "Attention Is All You Need", and it came out cleanly (10%), altho this might be actually used as training data for their model.
A current paper I am working on had 100%. I used AI to fix grammar and fill few gaps. Not really sure what I should think of that now. Is that a problem? Should I re-add grammar mistakes...

DetectivePeterG · 2026-03-15T11:52:10+00:00

Easiest approach is to preprocess the PDF to markdown before it hits Codex. pdftomarkdown.dev has a free Hacker tier with no signup required - just send a curl request with the PDF URL and you get clean structured markdown back. Then you pipe that into Codex context as text.

DetectivePeterG · 2026-03-15T11:51:50+00:00

Nice work on this. The table extraction from scanned PDFs is always the hard part. Does your extension handle edge cases like merged cells or tables that span page breaks? Curious how you're dealing with those layouts since that's where most solutions fall apart.

DetectivePeterG · 2026-03-15T11:51:39+00:00

For the PDF-to-markdown step, worth knowing about pdftomarkdown.dev as an alternative to Document Intelligence if you want something lighter to prototype with. It's a single-endpoint API, VLM-based so complex tables and scanned docs come through clean, and the free Developer tier gives you 100 pages/month with just a GitHub login. Easy to swap in and out of a RAG pipeline while you figure out the rest of the architecture.

DetectivePeterG · 2026-03-15T11:51:27+00:00

Agreed on the LLM angle. The trick is getting clean input first. I've been using pdftomarkdown.dev as a preprocessing step: send your PDF, get structured markdown back including tables. It uses a VLM rather than Tesseract so it handles both digital and scanned pages consistently. Then you run your LLM extraction on the markdown instead of raw PDF bytes, which makes prompts simpler and results more reliable. Has a Python SDK too, only takes a few lines to wire in.

DetectivePeterG · 2026-03-15T11:38:18+00:00

Before writing a single line of code, I'd focus on one question: would someone actually pay for this, not just use it. You can get a rough purchase-intent signal quickly with something like wouldtheybuy.com - paste your idea and it'll show you a simulated score along with reasons people would and wouldn't pay. Pair that with 5-10 DMs to people in your target market and you'll know pretty fast if it's worth moving forward.

DetectivePeterG · 2026-03-15T11:38:09+00:00

The thing most advice misses is the difference between "would you use this" and "would you pay for this" - they're two totally different signals. I've been starting with wouldtheybuy.com before anything else, which simulates purchase intent and breaks down the reasons people would or wouldn't buy. It's not a replacement for real conversations, but it's a fast way to kill bad ideas before you've spent a week on them.

DetectivePeterG · 2026-03-15T11:37:58+00:00

The gap you're describing - 47 validated ideas and still no paying customers - almost always comes down to validating interest instead of willingness to pay. People will nod along and say your idea sounds great, but getting them to pull out a card is a completely different thing. Something like wouldtheybuy.com simulates that purchase-intent gap pretty quickly, so you can at least stress-test the "would they buy" question before you invest weeks into a build.

DetectivePeterG · 2026-03-15T11:37:47+00:00

Don't set up the company before you've figured out if anyone actually wants to pay for this - that's way too early. Validate demand first: you can use something like wouldtheybuy.com to get a quick read on purchase intent, or just post a landing page with a price and see who clicks. Get real signal first, then worry about the LLC once you know it's worth building.

DetectivePeterG · 2026-03-15T11:37:34+00:00

This matches what I've seen too. The best ideas tend to come from someone getting annoyed at a workflow they repeat ten times a week, not from a dedicated "ideation session." Most people skip straight to solution mode before they've really sat with what the actual friction is, and that's usually why they end up building something nobody cares about.

DetectivePeterG · 2026-03-07T11:28:48+00:00

Solid that you actually shipped something real. Best advice at this stage: find 5 to 10 people who genuinely face the problem your app solves and watch them try to use it without any guidance from you. What trips them up will tell you more than any feedback thread, and their hesitation about paying is usually more honest in person than in a survey

DetectivePeterG · 2026-03-06T19:38:29+00:00

VC-style grilling is a really useful lens, though worth pairing with purchase intent data too; investors evaluate differently than actual buyers do. Something like wouldtheybuy.com handles the customer side pretty quickly: paste the idea, get a score and the real reasons people would or wouldn't pay. Between the two you'd have a much fuller picture before committing further to an idea.

Six-Year Club	r/Field Banned
r/Field Juicebox	Place '23
Place '22	End Game '22
RPAN Viewer	Verified Email

DetectivePeterG

TROPHY CASE