Original Summary

I’ve been building Openbound, a job search product for people who need visa sponsorship in the US. The initial idea sounded straightforward: Take job listings, combine them with historical H-1B / green-card sponsorship data, and help candidates understand which jobs are actually worth applying to. The product now tracks roughly 300K active jobs across 2,500+ employers. But most of the work ended up being a data reliability problem rather than a search or UI problem. A few things I learned: 1. “The company sponsors visas” is not the same as “this job sponsors visas.” I ended up separating three signals: what the individual job posting says the employer’s historical visa sponsorship behavior the employer’s green-card sponsorship history Combining them into one opaque “sponsorship score” would have been easier, but also misleading. 2. A successful API request doesn’t mean you have the employer’s job inventory. Employers use Workday, Greenhouse, Lever, Eightfold, Oracle HCM, SmartRecruiters, and a surprisingly long tail of other systems. Some APIs paginate normally. Others cap results. Some boards require facet partitioning to enumerate everything. Some career sites are only front ends for a completely different ATS. The dangerous failure mode isn’t an error. It’s getting 300 jobs back from a company that actually has 2,000 and confidently assuming you have everything. If you then expire everything you didn’t see, a technically “successful” sync quietly deletes valid jobs. That changed how I think about product reliability: a system that fails loudly is often much safer than one that returns plausible incomplete data. 3. More data isn’t automatically better. We deliberately exclude or scope parts of some employer boards when the inventory is overwhelmingly retail, hourly, clinical-care, or otherwise outside what professional visa-constrained candidates are looking for. A 20,000-job employer isn’t necessarily more useful than one with 200 highly relevant roles. 4. I underestimated how much of a SaaS product becomes operational infrastructure. The visible product is job search. Behind it are ingestion, freshness checks, source verification, employer identity resolution, duplicate protection, sponsorship evidence, failure recovery, and rules for when a source should not be trusted. That has probably been the biggest lesson from building it. The product is Openbound : https://theopenbound.com It’s free right now. I’m mainly trying to make the underlying sponsorship/job data trustworthy before thinking seriously about monetization. For other founders working with aggregated or third-party data: How do you decide when imperfect data is good enough to ship versus when the uncertainty itself needs to become part of the product?   submitted by   /u/Guilty-Sector-9958 [link]   [comments]

  • 情报分类：工作与职业机会
  • 分类依据：内容涉及招聘、求职或职业发展
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/9/30 11:43:14