Most sites cap pagination somewhere: page 50, page 100, a total result ceiling. Wellfound does not, and the absence of a limit turns out to be harder to plan around than a limit would be.
No site-wide limit
Each role paginates until its own corpus is exhausted, at which point the site redirects rather than serving an empty page. There is no global page number where everything stops.
The measured ceilings
| Role slug | Pages before redirect |
|---|---|
engineer | 130 |
software-engineer | 91 |
office-manager | 37 |
Why a page cap produces uneven coverage
Set maxPagesPerRole to 40 and you get all of office-manager, a bit under half of software-engineer and under a third of engineer. Nothing in the output distinguishes “this role has no more jobs” from “this role hit your cap”, so a dataset built that way has a coverage bias that is invisible in the data itself.
Cap on rows instead
maxJobs bounds delivered rows, which is the cost unit and the thing a plan is about. It also fails predictably: when it stops a run, it stops it for a reason you set.
Estimating a run
About 28 unique jobs per listing request, and about 1,950 unique jobs per role on average. Three roles across two locations, uncapped, is therefore several thousand rows and a bill to match — which is the arithmetic to do before starting rather than after.
