Why We Built Remotato

If you've looked for a remote job in the last few years, you know the feeling: you filter for "remote", scroll through dozens of listings, and half of them turn out to be hybrid, or "remote-friendly," or just New York City with a flexible Friday policy. The word remote has been stretched so thin it's nearly meaningless.

That frustration is why we built Remotato. Not as another aggregator. Not as a LinkedIn clone. But as a job board built from first principles around one idea: if it says remote, it means remote.

The problem with existing boards

Most job boards have the same architecture: companies post (or pay to post), the board ranks them, and job seekers search. That model works reasonably well when you're hiring locally. But remote work broke the assumption.

Here's what we kept seeing:

• Duplicate listings everywhere. Job boards scrape each other. A single listing from Stripe's Greenhouse account might appear on six different boards with slightly different formatting — and three of them show it as still open two months after it closed.
• "Remote" that isn't remote. "Remote (US only)" is fine — but "remote-friendly" is not the same as remote. "Flexible location" often means you're expected in the office twice a week. Job boards don't enforce a definition, so companies use whichever tag gets the most clicks.
• Paid placements over real jobs. Most major boards let companies pay to rank higher. That means a company that cares about SEO gets more visibility than a company that cares about engineering. Job seekers end up optimizing for the wrong signal.
• No freshness guarantee. A listing from 90 days ago sitting at the top of search results is pure noise. But removing it costs the board ad revenue, so it stays.

Our approach: go straight to the source

The insight that unlocked Remotato was simple: most legitimate remote-first companies already publish their open roles through an ATS — Greenhouse, Lever, Ashby, Workable, or SmartRecruiters. These systems have public APIs. If you pull from those APIs directly, you bypass the scraping problem entirely.

So that's what we built. A pipeline that:

1. Fetches job listings directly from company ATS APIs on a regular sync cycle
2. Normalizes remote type into four explicit categories: fully_remote, remote_us, remote_eu, and hybrid — with no ambiguity
3. Auto-detects when a listing is removed (the role was closed) and marks it as gone the next sync
4. Deduplicates by company + job ID so the same role never appears twice

The result is a board where every listing is live, every listing is genuinely remote, and every listing came from the company's own hiring system — not a scraper.

The technical stack

We chose a small, sharp stack:

• Next.js 16 (App Router) — server components let us ship fast pages with real data without client-side fetching waterfalls. The app router's nested layouts made building the admin and job board sections clean.
• Supabase — Postgres with row-level security. Every user can only access their own data. Storage for resumes. Auth for login. All three in one platform, no glue code required.
• Tailwind CSS v4 — the CSS variables approach in v4 made our design tokens (coral, warm beige, dark background) maintainable without a custom design system.
• TypeScript throughout — strict mode. If it compiles, the data shapes are trustworthy end-to-end from Supabase to the component.

The ATS integrations are the most interesting technical piece. Each system has quirks:

• Greenhouse's board API is public and requires no auth, but their job location fields are inconsistently structured across companies.
• Lever normalizes things slightly better but their remote field is a free-text tag — so "remote", "Remote", "REMOTE", and "remote-us" are all different values.
• Ashby has the cleanest structure but the most permissive fields, which means companies can put anything in the location.
• Workable uses a REST API with cursor-based pagination that needs careful handling to avoid missing listings on large accounts.

We solved this with a normalization layer that runs on each fetched job before it hits the database. It applies regex patterns, keyword matching, and country lookups to collapse the chaos into the four canonical remote types.

AI features: why and how

We knew from the start we wanted AI features — but not AI for the sake of it. The question was: where does AI actually help a job seeker, and where is it just noise?

The answer we landed on: AI is useful at the seams — the moments where the job seeker has found a role they care about and needs to act quickly and specifically.

Three use cases stood out:

1. Cover letter generation. Writing a cover letter for every application is the job seeker equivalent of boilerplate code — necessary but tedious. A model that can read a job description and a resume and synthesize a 3-paragraph letter that's actually personalized saves real time. We use Claude (claude-opus-4-8) for this because the output quality on writing tasks is noticeably better than alternatives.
2. Resume optimization. Most people have never had their resume reviewed by a recruiter. An AI that can score a resume against best practices and give specific, actionable feedback — not generic tips but "your bullet points don't have measurable outcomes in section 2" — is genuinely useful.
3. Job match scoring. Before spending 30 minutes on a cover letter, it's worth knowing: do I actually have the skills this role requires? A quick match check against your resume prevents wasted effort.

We use a token model rather than a subscription because AI compute costs are variable and job searching is episodic — you might apply to 5 jobs in a week, then nothing for a month. Charging $20/month for that pattern is unfair to the user. With tokens, you pay for what you use, and unused tokens don't expire.

What we learned building the first version

A few things surprised us during the build:

• Remote type normalization is an unsolved problem. Even after months of work on the normalization logic, edge cases keep appearing. Companies use free text in ways no regex fully anticipates. We've accepted that this is an ongoing process, not a shipped feature.
• Job freshness matters more than we expected. The sync cadence is hourly, and even within a few hours, popular roles can close. We added a first_seen_at timestamp to surface genuinely new listings first instead of just most-recently-posted.
• The visual design carries more trust signal than the copy. Early versions of the site looked like every other job board — clean, functional, forgettable. The iteration to a warmer, more distinctive visual identity (the coral palette, the dark hero) noticeably changed how people described the product in feedback sessions.
• PKCE OAuth is fiddly in Next.js with SSR. The Supabase auth flow requires cookie-based session storage that spans a server redirect. If you're using @supabase/ssr v0.12+, the cookie client must use getAll/setAll instead of the old get/set/remove pattern — otherwise the PKCE code verifier gets dropped mid-flow and Google login silently fails. Took us longer than it should have to find this.

What's next

We're just getting started. On the near-term roadmap:

• More ATS sources. We want to cover every major remote-first company. There are hundreds of companies using Rippling, BambooHR, and other systems we haven't integrated yet.
• LATAM and global remote coverage. Right now coverage skews US/EU. Remote work is a global opportunity and our index should reflect that.
• Application intelligence. As users track applications, we can surface patterns: which companies respond fastest, which roles have the highest interview rate, which skills are most in demand right now.
• Alerts. Tell us what you're looking for and we'll email you when a match appears. One token per alert, no subscription required.

We built Remotato because we were frustrated with the status quo and believed a better experience was possible. If you're in a remote job search, we hope it makes the process a little less exhausting.

Browse the board →