DEV Community

Cover image for RamenHire: Two Readers, Two Different Signals, One Problem
Lior Karaev
Lior Karaev

Posted on

RamenHire: Two Readers, Two Different Signals, One Problem

Weeks apart, in completely different contexts, two people pointed at the same gap from opposite directions. One was a technical comment on a security post. The other was a real job seeker who found a dead listing.

The technical version of the warning

A while back, a reader pointed out something obvious in hindsight: I'd curated a batch of real job listings all at once, early on, with no plan for what happens when they go stale. His actual point was sharper than "add an expiry date" — an expiry keyed off creation date only protects listings made after you ship it. The existing batch, seeded all on the same day, would need the fix backfilled onto it directly, or it'd sit there exactly as unprotected as before.

I filed it. Correctly identified, not yet urgent — no user had hit it yet.

The real version of the warning

Then one did. A subscriber — a real job seeker, in the middle of an actual search — wrote in with detailed, specific feedback. One line: a Kinsta listing she'd clicked into no longer existed. She'd taken the site at its word, gone looking, and found nothing there.

Same problem the comment predicted, now with a real person on the other end of it.

What actually shipped

Removed the dead listing. But the harder fix wasn't the listing — it was resisting the instinct to solve staleness with more automation. My first idea was having something re-check every listing against the live web on a schedule. Worth naming why I didn't do that: the entire point of building real company accounts was to stop being the middleman who manually keeps every listing accurate. An automated re-scrape doesn't fix that — it just moves the manual burden one layer over, from "check my email" to "review what a script changed while I wasn't looking."

So, two different mechanisms instead of one blanket fix:

  • Real expiry, wired only to listings created through the new self-service company accounts. A company that made the listing can keep it current or let it lapse — their data, their responsibility.
  • For the original hand-curated batch — no auto-expiry, since they were all seeded within days of each other, and a uniform expiry window would've deactivated most of the site's content at once. Instead: an honest age indicator on every listing, so a job seeker can judge freshness themselves instead of trusting a "current" badge that might not be.

The other thing she flagged

Same message, second point: clicking "Apply" dropped straight into an intake form, no full job description, no confirmed salary or location first — asking someone to commit before they'd actually seen what they were committing to. Real gap, unrelated to staleness, just as worth fixing. Every listing now has a real detail view before the apply step, not after it.

The honest part

To keep the board from looking abandoned while real registrations are still building, I had a research pass find a handful of new, genuinely open roles from companies already featured on the site — verified the same way the original batch was, against real careers pages, not an aggregator. This is a bridge, not a strategy. It's supposed to shrink as an activity as real companies register and post for themselves, not become a standing job.

Real registered companies, still: building toward the first one. Two people, in two completely different registers — a security-minded reader and someone actually job hunting — pointed at the same weak spot from opposite directions, and neither of them owed me the time it took to write it out.

Top comments (0)