Back to portfolio
Job tech · Product management

Fresh Jobs. No Noise.

“Built for speed and freshness. No stale jobs, ever. Real-time alerts ensure users apply first, not last.”
A real, live job-discovery platform: the product reasoning behind it, including the times it broke and what that changed.
Role
Product Manager (side project)
Built
Claude & ChatGPT as engineers
Timeline
2026 – Present
Product
Live product
17×
Single-day traffic surge, survived
12 days
Longest silent outage, since fixed
2
Live dashboards below, updating right now
01

Background

The market didn’t have a data problem. It had a freshness problem - every tool people had already tried, paid or free, kept showing the same handful of stale postings.
The recurring complaint
Every existing tool showed the same handful of stale postings. The gap wasn’t volume - it was freshness.
What that actually cost
Hours a week manually checking company pages, and popular roles closing within hours - the early-applicant window was what people were really losing.
The gap incumbents leave
Specialized roles (ML, RevOps, AI Engineer) live on a company’s own career page long before an aggregator-of-aggregators picks them up.
Exhibit: roleradar.xyz, live right now
RoleRadar's real 'Why Freshness Matters' comparison: job posted 2 min, visible 4 min, applied 5 min, -3 applicants vs. other job sites: day 0, 2-5 days, day 5+, 200+ applicants

Screenshotted directly from the live product - this is the comparison shown to every visitor.

02

The problem RoleRadar solves

Real-time company-page monitoring - watching the source directly instead of building yet another aggregator of aggregators.
The traditional chain, and where RoleRadar cuts in
Job posted on career page
RoleRadar cuts here
Days of lag
→
Appears on Indeed / LinkedIn
→
Job seeker discovers it

Most job boards depend on the lag between a company posting a role and it reaching Indeed or LinkedIn. RoleRadar monitors company career pages directly, skipping that dependency entirely instead of trying to crawl the aggregators faster.

Alternatives considered
Chosen
Real-time company-page monitoring

Skips the lag to aggregators entirely by watching the source directly.

Not chosen
A resume or interview-prep tool

More crowded, less differentiated than solving freshness.

Not chosen
A tech-only vertical

Throws away infrastructure that generalizes across roles for free.

03

What I considered instead

No head-to-head competitor to benchmark against here.
API-first, before a consumer UI
Two-way door - easy to reverse
Alternative I didn’t buildBuild a polished consumer app first
WhyConsumer UX needed many iterations to get right - an API let interest plug in immediately while the core data engine matured.
Freshness over coverage, first
Two-way door - easy to reverse
Alternative I didn’t buildMaximize company coverage, then optimize speed
WhyThe recurring complaint was staleness. A smaller always-fresh set beat a large stale one.
Email alerts as the MVP
Two-way door - easy to reverse
Alternative I didn’t buildFull web app with search and filtering
WhyProved demand for “fresh jobs delivered to you” before investing in a UI at all.
Coverage got cut before quality did
Two-way door - easy to reverse
Alternative I didn’t buildThin coverage everywhere, all at once
WhyNarrowed to the highest-density states first on a bootstrap budget, rather than spreading thin nationwide.

Every early decision here was deliberately reversible - the actual instinct of a bootstrapped one-person build, where cheap to undo beats optimal but locked-in.

04

Assumptions I'm making

Each one labeled by how it actually got tested.
Users would trust an unknown aggregator
Alternative I didn’t buildAsk for trust on faith
WhyBuilt a public live-data dashboard instead - see section 06.
An email-only MVP proves real demand
Alternative I didn’t buildBuild the full web app first, then find out
WhyShipped the email alerts before a web app existed at all.
05

Risks I was watching for

Three real incidents, pulled from the platform's own history.
Fixed
Growth arriving before the infrastructure did

A traffic surge in January was the first real signal of demand - visits jumped roughly 17× overnight and stayed elevated for a week. It also proved the infrastructure was sized for steady-state traffic. The real risk was finding out the hard way whether the platform could hold on to users the moment they actually showed up.

Daily pageviews, Jan 15–Feb 5 2026
typical day: ~90 pageviews
05001,0001,500928 (Jan 22)1,707 (Jan 23)Jan 15Jan 18Jan 26Jan 30Feb 2Feb 5
Fixed
Free-tier infrastructure came with a real trade-off

Running on a free-tier database kept runway intact during validation, but its connection limits had a ceiling that hadn’t been stress-tested. When it was hit, the site went down for real users in production. The fix was removing a connection leak that shouldn’t have existed at any tier, which mattered more given the bootstrap budget.

Fixed
A silent failure is worse than a visible one

The whole product’s pitch is freshness. When the pipeline broke on one bad listing, it broke silently for 12 days - nothing surfaced it because scraping still looked like it was running underneath. Users would have noticed before I did. Promising freshness without instrumenting for “is it actually still fresh” was an incomplete feature.

Day 0
One bad listing
A scraped pay range came through as “$1–$9,000,000,000”
Every run
Silent, identical failure
That number broke a required step, so the pipeline aborted at the same point each cycle
12 days
Invisible
Raw scraping kept running quietly, so nothing looked obviously down - no alert on repeated identical failures
Fixed
Traced & patched
Found the exact listing, fixed the number handling, added alerting for repeated failures
06

How this connects to outcomes

Real user behavior from the product, all time, refreshed every week.

Loading metrics...

Get in touch

Let’s talk about what you’re building.

Interested in how I can help your team ship faster? I’d like to hear what you’re working on.

Book a 15-min chat Connect on LinkedIn