Should I vibe code
Desktop scraper with selectors, pagination, scheduling, and cloud runs
Point-and-click was the product. Agents made that free and left you holding the part that never got easier.
?
Their verdict, the Standard price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Worth saying first, because the tail of this category is littered with corpses: ParseHub is still trading. The site works, the checkout works, the desktop app has shipped this decade. What has changed is the thing it sold. ParseHub's actual product was never the scraper — it was letting somebody who does not write code teach a scraper by clicking two examples and having it infer the rest, which was a genuinely hard piece of engineering and worth paying for. An agent that reads HTML and returns a selector has made that free. So the build case here is the strongest anywhere in this cluster, and the price sharpens it: $189 a month is $2,268 a year, several times what the hosted platforms charge, for a tool whose hardest feature you can now get from a prompt. None of which changes the risk, and that is the entire point of this site. What you inherit is not the selector, it is every target site forever, a request rate somebody else's server absorbs, rows that quietly contain people, and the failure mode this category is defined by: extraction that half-works and writes a plausible, incomplete dataset instead of an error. Easy to build, cheap to justify, and still the same funeral.
What actually breaks
not "if". the specific failures.
- Selectors written against one rendering of a page, on a site that serves several. Layout tests, regional templates and logged-out variants mean your extractor works on some responses and not others, which is far harder to spot than an extractor that works on none
- The drop-empty-rows step, which is in every one of these pipelines and quietly converts partial failure into a biased sample. You are left with a dataset that looks clean and represents whichever pages happened to parse
- Pagination, the moment 'next' becomes a cursor, a scroll listener or a POST. The two pages you tested go fine and page nine returns the same twenty rows forever
- IP rotation, which is bundled on the paid plans and is the component you are least equipped to replace responsibly. Sourcing proxies means either paying for infrastructure you cannot audit or getting your own address blocked
- Politeness under retry, because the harm is not steady volume — it is a timeout that triggers a retry that times out, turning a job designed to fetch a thousand pages into a sustained load test against a host that was already slow
- Headless browser cost and flakiness, which arrive together on the first site that renders in JavaScript and never leave
- Retention, in the opposite direction to the vendor's. ParseHub deletes your runs after two weeks; your version keeps everything forever, including the names and profiles you did not mean to collect
- The scheduler with a lid on it, if the runner is the laptop you close at night. A scraper that misses Tuesday leaves a hole nothing downstream will mention
- Login walls and anti-bot checks, which is the point where the project stops being data collection and becomes evasion, with a different set of consequences
The quarterly pricing review is where it comes apart. The average competitor price your scraper reports has been drifting down for two months, which fitted the story everyone already believed about the market, so nobody looked hard at it. What the target site did in April was start an A/B test on its product template. Roughly forty per cent of requests get the new layout, in which the price sits in a different element, and your extractor returns nothing for those. Your pipeline drops rows with an empty price, because that seemed obviously correct when you wrote it, and reports a clean run every time. So the dataset is a sixty per cent sample — and not a random one, because the bucket assignment follows the request, and you rotate proxies, so which products got measured changes every run in a way you cannot reproduce or even describe. The averages are computed over whichever listings happened to fall into the old template that day. Two quarters of positioning decisions rest on that, the archive of raw responses that would let you reconstruct the real figures was never kept, and there is no way to go back and find out what the market was actually doing in May.
Is that you?
the verdict is a default, not a law
- It reads one site, on a schedule you could recite, and you would notice within a day if it stopped
- You own the site, or you have written permission to read it
- Every field has an assertion that fails the run loudly rather than writing a null
- You are collecting facts and numbers, not people
- The raw response is archived next to every parsed row, so a wrong number is traceable to a date
- Rows with missing fields are silently dropped, which is the default behaviour of every pipeline in this category and the reason the datasets are wrong
- The results feed a decision, a price or a report that nobody reads the underlying numbers for
- You are collecting names, emails, reviews or profiles belonging to real people
- You cannot say what request rate a given target host is receiving from you right now
- The plan involves getting past a login, a paywall or a bot check
- You are running scrapers you no longer remember writing
If you build it anyway
the checklist, then the prompt that enforces it
- Assert the shape of every extraction. A required field that fails to parse must fail the run and write nothing, and a run that produces fewer rows than expected must complain. Never drop empty rows quietly — that is how a broken extractor becomes a biased dataset.
- Alert on completeness, not just on errors: rows extracted versus pages fetched, per run. A ratio that moves is the earliest and clearest signal that a site changed under you.
- Archive the raw response with every parsed row, under a retention limit. It is the only thing that lets you answer what a number really was in May.
- Write selectors defensively — anchor on text and structure rather than generated class names — and expect several templates per site rather than one.
- Apply a global per-host rate limit and concurrency cap shared across every job, so ten scrapers cannot combine into a load test against one domain, and cap retries so a slow origin does not amplify itself.
- Send a descriptive user agent with a contact URL, honour robots.txt, and use conditional requests. Being identifiable and cheap to serve is what keeps you from being a problem and from being blocked.
- Cap pages, crawl depth and wall-clock time before the first run. Faceted search, infinite calendars and session-id URLs will find an unbounded loop before you do.
- Decide deliberately before collecting anything that describes a person, and set a retention deadline at write time. There is no side-project exemption from the duty you take on when the rows contain people.
- Run it somewhere that stays awake. A scraper scheduled on a laptop is a dataset with unexplained gaps in it.
I am building a scraper for a handful of sites, replacing a visual tool. The
failure I am worried about is not a crash, it is a dataset that looks complete
and is not. Apply these in order and push back where noted.
1. Ask me how many sites I am actually scraping. If it is one or two, build
scheduled scripts and refuse to build a framework.
2. Make every extractor assert its own output: required fields present and
type-checked. A missing required field fails the row loudly.
3. Never silently drop rows with empty fields. A partly-broken extractor plus a
drop-empties filter produces a biased sample, not a smaller one — say so.
4. Emit a completeness ratio per run — pages fetched versus rows extracted —
and alert me when it moves. Tell me this is the earliest signal that a site
changed its template.
5. Assume each target serves several templates: layout tests, regional variants,
logged-out versions. Write selectors anchored on text and structure, not on
generated class names, and handle the miss explicitly.
6. Store the raw response body alongside every parsed row, with a retention
limit, so I can reconstruct what a value actually was.
7. Enforce a global per-host rate limit and concurrency cap shared across all
jobs, and cap retries so a slow origin cannot amplify one job into a load
test.
8. Send a descriptive user agent with a contact URL, honour robots.txt, and use
ETag and If-Modified-Since.
9. Cap pages, depth and wall-clock time per run before the first fetch.
10. Refuse to bypass logins, paywalls, bot checks or CAPTCHAs. If a target
requires it, the answer is an API or an email, not better evasion.
11. Before writing any extractor that captures names, reviews, profiles or user
content, stop and tell me that makes me a controller under GDPR with duties
to the people in those rows, and ask my lawful basis.
12. Out of scope unless I ask: proxy rotation, fingerprint spoofing, and running
this on my laptop, which will give the dataset gaps I cannot explain.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
This is the one entry in the scraping cluster where the buy case is genuinely weak. $189 a month is $2,268 a year, several times what the hosted platforms with better infrastructure charge, and the feature it was uniquely worth paying for — teaching a scraper by clicking rather than by coding — is the one thing an agent now does for nothing. If you are non-technical and the point is that you never touch code, it still earns its price, and the IP rotation and cloud scheduling are real. If you can read a selector, the honest advice is not to buy this and not to build a platform either: write two Scrapy or Playwright jobs with the assertions above, and if you outgrow that, look at the $29-a-month hosted tier before you look at this one.
Own the data rather than the tool, which is easier here than in most of this cluster because there is nothing proprietary to escape: rows in your own database, raw responses archived beside them, a fetch timestamp on everything. Keep one file listing every target with its rate limit, its robots decision, the date its terms were last read and the date its markup last changed — that file is the difference between handing this to somebody and asking them to rediscover it from the code. If you are leaving a hosted tool for your own scripts, export before you cancel, because the two-week retention window on the Standard plan means the runs stop being recoverable very quickly after the card does.
Scrapy's visual point-and-click scraper builder, archived by its owner in 2026 and worth looking at as evidence of what happens to this category.
Browser-based visual extraction with sitemaps and pagination, untouched since 2018 but still the clearest illustration of the selector-inference idea.
The mature Python crawling framework, where throttling, retries, pipelines and item validation are already solved.
Questions
Is ParseHub still running, or is this another dead scraper?
Running. The site is up, the pricing is live, the checkout works and the desktop client has had releases in the last year or so, which is more than several products in this corner of the market can say. It is fair to describe it as a mature tool in low gear rather than one under active expansion — the pricing page still boots Stripe's long-deprecated legacy checkout script, which tells you something about how often the marketing site gets touched — and vendor longevity is a legitimate thing to weigh when a pipeline is going to depend on it. But nothing here is an obituary.
If the build case is that strong, why is the verdict YOUR FUNERAL?
Because the verdict is not about difficulty and never has been. Everything that got easier is on the authoring side: writing the selector, handling pagination, parsing the page. Everything that makes scraping a bad idea to run casually is on the other side of the fetch, and none of it moved. You still hammer a server whose owner never agreed to anything, still collect personal data as a side effect, still inherit every target's markup as a permanent maintenance obligation, and still get a broken extractor that reports success. Cheap and easy is what makes it likely, not what makes it safe.
Why is a partly-broken scraper worse than a completely broken one?
Because a completely broken one tells you. Zero rows is an alarm anybody notices. A scraper that parses six pages in ten and drops the other four produces a clean-looking file, a green run and a number that is subtly wrong in a direction nobody can characterise — and if the misses correlate with anything, which under a layout test they do, the sample is skewed rather than merely small. The defence is two lines: never drop empty rows silently, and alert on the ratio of rows extracted to pages fetched.
- GDPR Art. 6 — lawfulness of processing (the basis you need for scraped personal data)
- GDPR Art. 14 — information to be provided where data has not been obtained from the data subject
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
One scraper is a weekend. Forty scrapers is a job, and the site you are hammering never applied for it.
The free tier already scrapes. The $119 buys residential proxies and CAPTCHA solving — a price list for a refusal.
Your scraper counts HTTP 200s. The invoice counts successful queries. Those have never been the same number.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice