TL,DR
If you’re in Latin America and you want a real remote job, the big job boards waste your time. A huge chunk of what they call “remote” is actually US-only and nobody filters that out for you, because the aggregators make money on volume, not on saving you the disappointment.
This platform is the opposite bet. It scrapes company career pages directly, rebuilds every posting into structured data, and then makes an explicit, testable decision about who each job is actually open to. What survives gets published. The pitch to a candidate is simple: everything you see here, you can actually apply to.
The same machine runs a second, English-language board: Build With Talent that opens things up to global roles, US included. Both boards share one engine. The only thing that differs is the rulebook for who gets in. That’s the whole design: build the hard part once, and let each board bring its own policy.
Who it’s for
LATAM remote seekers: mid-to-senior people in Argentina, Brazil, Mexico, Colombia and around the region who want remote work at global or regional companies, and are tired of applying into roles they were never eligible for. Spanish interface.
Global seekers (BWT): English-speaking candidates who’ll take remote work anywhere, US included. Same freshness and legitimacy guarantees, wider net.
Goals
- Relevance: every LATAM listing is plausibly open to a LATAM candidate.
- Freshness: closed and stale roles are gone within a day.
- Legitimacy: ghost jobs and “talent pool” postings get caught and suppressed.
How it actually works
It’s a six-layer pipeline. The first three layers are shared across every board; the last three belong to each board individually. That split is the most important decision in the whole thing: the expensive, easy-to-get-wrong work, fetching jobs and understanding them, happens once, and a board only owns its own policy.
| Layer | Does | Shared or per-board |
|---|---|---|
| 0 · Source | Which career pages to scrape, and how trustworthy each source is | Shared |
| 1 · Capture | Pull raw postings from ATS APIs snapshots only, no interpretation | Shared |
| 2 · Normalize | Turn free text into structured facts: location, area, seniority, modality, salary, skills, language | Shared |
| 3 · Classify | Apply the board’s policy: READY / REVIEW / REJECTED | Per board |
| 4 · Publish | Sync approved jobs to the board’s live feed | Per board |
| 5 · Lifecycle | Remove closed, expired or stale roles | Per board |
Job sources
Supply is scraped straight from company career pages across seven applicant-tracking systems, roughly 3,200 active sources. Going direct to the ATS instead of through an aggregator means fresher data, a clean apply URL, and no middleman noise.
Turning messy text into facts
Raw postings are a mess because location is a free-text blob, the area is only implied by the title, salary is written a dozen ways.
Layer 2 rebuilds each posting into clean, queryable facts so that filtering, geo policy and quality scoring have something solid to stand on.
Classification
Classification is where a normalized job meets a board’s policy and lands in one of three buckets: READY (publish it), REVIEW (a human should look LATAM only), or REJECTED (suppressed, with the reason recorded). Every decision writes down its reason — “US-only,” “LATAM + remote,” “area excluded,” “stale” — so you can always ask any listing why it ended up where it did.
The trust machinery
Three subsystems exist for one reason: to protect the candidate’s trust. This is the “curate, don’t aggregate” thesis made real.
Geo-legitimacy detection. A tiered signal model reads each posting for tells that it’s quietly US-only — from the decisive stuff (explicit US work-authorization language, US state licenses like RN/CPA/bar, US pay-transparency disclosures) down to the soft stuff (US-boilerplate EEO language, the absence of any global-hiring language). Signals get scored and bucketed from “ok” through “suspicious” and “likely US” up to “US-only.”
Ghost-job and source reliability. Sources are audited for the patterns that give away ghost jobs like roles that close within days of opening; a role closed and reopened within 30 days under a near-identical title; the same title closed three or more times in 90 days (the classic talent-pool move). Sources get flagged ok / suspicious / red-flag, and those flags feed back into classification. Protective caps stop one noisy signal from unfairly nuking an otherwise healthy source.
Quality scoring. Every posting gets a 0–100 completeness score across description depth, location clarity, recency, salary, area, title specificity and a working apply link. Below about 40, the job is forced into review even if it passed geo policy. A thin listing is treated as a risk, not a free pass.
Metrics
Clicks are tracked with a lightweight pixel, each job or CTA click fires a beacon into a log that syncs back into the database, where it powers both the analytics and the “hot job” badge. Tracked today: job clicks (with referrer and timestamp), banner/CTA clicks per board, and hotness (24-hour clicks vs. average).
Roadmap
Near-term
- Auto-consume the BWT publish backlog so overflow roles go live without a manual re-run.
- Finish other ATSs and grow the source base.
- Define and instrument the sourcing funnel end to end.
Medium-term
- Impression tracking, not just clicks, for a true CTR on listings and CTAs.
- Stronger language detection to tighten BWT’s English-only promise.
- Candidate saved searches / alerts, as a retention and newsletter-growth lever.
Long-term
- A feedback loop from apply-through data back into source ranking and quality scoring.
Lessons learned
- Trust beats coverage. A LATAM candidate need a page where everything is real, open to them, and still hiring. Choosing curation over volume meant deliberately shipping fewer jobs than the aggregators, and building the machinery to defend that choice: the geo filter, the ghost-job detection, the human-in-the-loop review that only fires on genuine ambiguity.
- The dangerous failure it’s the system being confidently wrong. Almost every serious bug was a parser sure of a wrong answer. The fix was always the same shape, make uncertainty escalate instead of guess, and lock it behind a test. That principle now sits in the code, not just the docs.
- Closing the loop: feeding apply-through data back into source ranking, so the board doesn’t just filter what’s good, it learns what candidates actually act on. That’s the difference between a curated list and a product that gets smarter every week.