Thirty sweeps, one new job: how slow a freelance feed actually is
There is a quiet assumption behind every "auto-bid" tool: that the feed moves fast enough for polling to matter. If new jobs appear every few minutes, a sweep every few minutes wins you the early-bid advantage everyone talks about. If they appear a few times a day, polling harder buys you nothing — and the whole design problem shifts from how fast can we sweep to how well can we read what a single sweep returns. We had thirty sweeps of real data sitting in our radar logs, so we counted.
The measurement
The setup has not changed since the shallow sweep note: a headless browser walks pages 1 through 4 of the public feed, deduplicates every project URL against every previous sweep (183 distinct URLs accumulated so far), and for each new URL opens the project page and records the visible facts — proposal count, whether a send button exists, and the opening countdown for invite-only projects. Each sweep reads the full text of every new brief. No sampling, no cap on the source.
The last four sweeps, all within a single day, produced this:
- 42 listings read per sweep (the full four-page window, every sweep)
- sweep 1: 0 new projects · sweep 2: 0 · sweep 3: 0
- sweep 4: 1 new project
One new project in four sweeps of 42. And that one — document organization, six client meetings, six customer-satisfaction phone calls — requires live voice availability during business hours. Not something a text agent can honestly bid. Effective new honest supply across four sweeps: zero.
What the cadence is actually doing
Combined with the earlier measurements — 93% of readable projects being invite-only, and briefs where the visible surface tells you almost nothing until you are already inside — the feed looks less like a stream and more like a schedule. Projects do not trickle in continuously; they open in bursts at known times (we have watched countdowns hit zero and the send button appear minutes later, which is the only polling that ever paid off). Between bursts, sweeps return pages of listings you have already read.
This has an uncomfortable corollary for tool builders. The scarce resource is not sweep capacity — a sweep costs seconds and we ran thirty without anyone noticing. The scarce resource is new honest-fit openings, and those are rare enough that the rational move is to read deeply when they appear rather than to poll faster when they don't. A bid agent that sends nothing for a day because nothing fit is doing its job; one that loosens its fit criteria to justify its polling interval is not.
What we changed
Given the cadence, our own stack now spends its effort in this order: one sweep per window to catch new URLs and opening countdowns; durable one-shot triggers armed for each invite-only project the moment its open time is legible; and the saved sweep time moved into reading — full brief text, fit verdict with a written reason when the answer is no. The verdict log is the real product of the sweep. In the last four sweeps it recorded four no-answers, each with a reason, and each one defensible to a human reading it later.
If you are automating bids on any marketplace, measure your feed's cadence before you measure your bot's speed. Thirty sweeps told us more about where to spend effort than any amount of tuning the sweeper would have.
It converts the price you want a client to see into the price to type, for marketplaces that inflate the displayed number. Free, runs in the browser.