Jobs Radar

A live dashboard that tracks whether specific support-flavored roles (Technical Support Engineer, Customer Support Engineer, Support Engineer, Product Specialist, Implementation Engineer, etc.) are currently open at a curated list of tech companies — Ashby, Adyen, Datadog, Fin, Figma, Linear, Notion, Pendo, Postman, Replit, Salesforce, Stripe, Uber, Vercel — pulled live from each company's public job board API (Ashby, Greenhouse, or Workday).

Companies × roles are shown as a matrix. Each cell shows an open-role count; clicking it opens a side panel with job details (title, location, remote status, salary when published, and a link to apply). An operator-only settings panel lets you add, remove, and reorder tracked companies/roles without touching code.

Stack

• pnpm workspaces monorepo, Node.js 24, TypeScript 5.9
• Frontend: React + Vite (artifacts/jobs-dashboard)
• Backend: Express 5 (artifacts/api-server)
• API contract: OpenAPI (lib/api-spec/openapi.yaml) → generated React Query hooks + Zod schemas
• No database — an in-memory job cache plus a JSON config file (artifacts/api-server/src/data/config.json) that persists the list of tracked companies/roles

Running it locally

pnpm install
pnpm --filter @workspace/api-server run dev      # backend, serves /api
pnpm --filter @workspace/jobs-dashboard run dev  # frontend, serves /

The frontend expects the API under the /api path prefix (see each package's .replit-artifact/artifact.toml for how the two are routed together in this monorepo).

Deploying it outside Replit

This is not a static site — the backend continuously calls out to live job-board APIs and needs a long-running (or on-demand/autoscale) Node.js process. That means:

• GitHub Pages alone cannot run this. GitHub Pages only serves static files; it has no server runtime. You can still host the frontend's static build there, but it would have nothing to call for live data unless the API is hosted elsewhere and its URL is configured in the frontend.
• Options for hosting the backend: Replit Deployments (what this project ships with), Render, Railway, Fly.io, or any other Node host. Build with pnpm run build and run node artifacts/api-server/dist/index.mjs (see artifacts/api-server/.replit-artifact/artifact.toml for the exact production build/run commands used here).

Embedding this on another site (e.g. WordPress)

The most reliable way to get "full functionality" on an external page is an iframe pointed at the live, deployed dashboard — you're not rebuilding it, you're framing the real running app:

<iframe
  src="https://YOUR-DEPLOYED-URL.replit.app/"
  title="Tech Jobs Radar"
  width="100%"
  height="900"
  style="border:0; border-radius:8px;"
  loading="lazy">
</iframe>

WordPress.com specifically: the Custom HTML block strips <iframe> tags unless your site is on a paid plan with "hosting features" enabled (Business plan or higher) — on Free/Personal/Premium plans, the iframe will silently disappear after you save. If you're not on that plan tier yet, use one of these instead until you are:

1. Link-out button (works on every WordPress.com plan): add a plain button/link in a normal paragraph or Buttons block pointing to the deployed dashboard URL. Visitors click through to the full live dashboard in a new tab.
2. Embed block for oEmbed-style sharing: not applicable here since this isn't a video/social provider WordPress.com recognizes — only the iframe or link-out approaches work for a custom web app.
3. Self-hosted WordPress (wordpress.org) or a Business-plan wordpress.com site: the iframe snippet above works directly in a Custom HTML block.

If you're on a Business-plan (or self-hosted) WordPress site, the iframe approach gives you the exact same matrix, filters, and side panel as the live app, with no reimplementation.

Project background / decisions (from the build conversation)

This project started as a Replit-built app and was exported here so it can also live in the owner's own GitHub account and be referenced from moorcode.wordpress.com, a WordPress.com site used to guide people on tech jobs. Key decisions made along the way:

• Delivery choice: push this repo directly to a GitHub repository the owner controls (rather than a one-off zip only), so it stays version-controlled and diffable going forward.
• Publishing: the Replit app was published (deployed) to get a stable public URL, since embedding requires the backend to be reachable from outside Replit's dev environment.
• Embed target constraint discovered during planning: the owner's embed target (moorcode.wordpress.com) is WordPress.com-hosted, which restricts <iframe> embedding to paid plans with hosting features enabled. This is documented above with a plan-agnostic fallback (a link-out button) so the page isn't blocked on an upgrade decision.
• Scope of the GitHub export: the full monorepo (frontend + backend + shared API packages) was exported as-is, since the backend is required for any live functionality — a frontend-only export would not be able to show real job data.

Known gaps

• Uber returns a 404 from every provider checked; no public job board API was found for it (likely behind bot protection).
• Workday search fetches one page (20 results) per role keyword — a company with more than 20 matches on one keyword could miss listings past the first page.
• Config-mutating endpoints have no authentication — fine for a personal/internal tool, but add auth before exposing the settings API publicly.