Radar: a paid job-matching B2C SaaS built in a week

TL;DR

Radar is a subscription product: you upload your CV, and every morning you get an email with up to five job openings that actually fit you, each one labeled Fits today, Stretch or Aspirational, with the reason in plain words. Everything else lives on a private page called My Radar. It costs USD 19 a month with a seven-day free trial.

I built it in one week, tested it with 8 real users, and in less than two weeks 15 people were using it.

It sits on top of the job board ETL that reads 9,700 company career pages a day. The board decides what the public sees; Radar decides what one specific person should see today. Same data, very different problem.

Along the way the matching engine was rebuilt once from the ground up, the evaluation set grew from 38 real verdicts to 196 (it passes 175), and I reviewed 551 individual job-to-person decisions by hand before they went out.

The biggest lesson: a matching system that only knows how to filter ends up sending nothing, and the people paying for it notice before your metrics do.

The situation

The job board already solved supply: fresh, verified, de-duplicated postings from the region. What it did not solve was the person on the other side: mid-career professionals with 20 or more years of experience, who do not have time to scroll 3,800 listings and do not trust that what they see is still open.

The data said why this group needed something different. Only about one in ten postings asks for eight or more years of experience; more than half ask for zero to five. For a senior person, the problem is not finding more listings. It is finding the very few that are looking for someone like them, before they fill up.

The promise had to be narrow and checkable: every morning, the few openings that are for you, published recently, still open, in a language you read, in a place you can work from. If there is nothing, no email.

Two constraints shaped the build:

• Zero new cloud. The matcher runs locally, on the same machine and database as the board. The only external services are email delivery, payments, a spreadsheet and the WordPress site.
• Privacy by design. CVs are processed in memory and deleted. Only derived features are stored: role titles, years, languages, skills. Consent is required before anything is written.

How it was built

Week one: build. The rule was zero new infrastructure. The board already traveled pipeline → Google Sheets → WordPress, so sign-up made the same trip in reverse: a form on the site, a spreadsheet, and a script that reads it at the start of every run. The matcher runs at the end of the nightly pipeline, on the same machine. Payments were a subscription link. Email went through a transactional provider on a verified subdomain. An early plan with two engines and a cloud API was dropped after one day: a product delivered as a daily email does not need a server answering in real time.

Testing with 8 real users. Before charging anyone, every email went to my inbox first. Eight real job seekers, in sales, operations, marketing, tech and project management, uploaded their CVs, and I sent them their matches by hand along with a question: what is wrong here? They answered with voice notes, and every answer became a test case. That is where the core of the product came from: the three labels, the one-line reason under each job, and the vote buttons that say why a job does not fit.

Under two weeks: 15 people using it. Once the labels and the review step were solid, the landing page went live with a seven-day trial. In less than two weeks, 15 people were receiving Radar every morning.

How the product works

1. Sign up. The landing page shows live numbers: how many postings were reviewed in the last seven days, from how many companies, and how many passed the filters. After the trial starts, a five-step form asks for the email where you want to receive Radar, your city and preferred modality, the roles and industries you are looking for (and the ones you are not), your languages, and your CV and LinkedIn profile. You do not fill in your years of experience or level: those are read from the CV. Within about ten minutes, your first matches show up on the same page.

2. Every morning, an email. Up to five openings, never more than two from the same company, never the same one twice. Each card has the role, the company, the modality and location, a two-line summary of what the job is about, and a label:

• Fits today: apply now.
• Stretch: possible with some effort, and the email says what is missing (“revolves around payments and fintech, which your CV does not show”).
• Aspirational: a direction for later.

Under each job there is a “How do you see it?” row: Good match, or a reason it does not fit: location, too senior, too junior, industry, too technical, not the kind of work, can’t apply from my country, not interested in the company. Every click is recorded and shapes the next day’s run. If there is nothing worth sending, no email goes out.

3. My Radar. A private page with everything the email did not fit: new this week, fits today, last 30 days, and the ones you marked. It also has your preferences (change your roles, city or frequency and they apply the next day), your account and help. Anything that was emailed and is still open always stays there.

4. Behind the scenes, before anything is sent:

1. Reading the person. The CV parser extracts role titles, years of experience (and how they were estimated), languages with level, and terms weighted by recency.
2. Matching. Each posting goes through area, modality, location, role, level and language, then gets a score.
3. Verification. Every candidate job is checked against the company’s own system. If it closed, it is dropped.
4. Human review. A page opens in my browser with every person’s profile next to each match and a one-line “why it got in.” I approve or strike each one.
5. Delivery. Automatic checks, then the email. Every link is tracked, every vote feeds the next day’s run.

Onboarding: seven days, one ask per day

A trial is seven days long, and most people decide in the first two whether something is worth their attention. So the trial got its own onboarding: one short email per day, written in my voice, each with a single ask. The job emails come separately, only when there is a match; these teach people how to get value out of them.

Every email does two jobs. It explains one part of the product, and it asks for one action that makes the matching better: what to exclude, which openings fit, which direction to search. By day four, a person on trial has told Radar more about what they want than their CV ever did.

Two details mattered more than I expected. Day 1 sets expectations: the first email usually arrives in 24 to 48 hours, some days there is nothing, and that is the product working, not breaking. Without that line, a quiet day reads as a broken product. And day 3 explains that the feedback buttons are not a survey: each reason changes tomorrow’s email. “Too senior” moves your level, “Industry” removes that sector, “Good match” finds more like it. People vote when they know it does something.

Shrinking the time to the aha moment

Radar’s aha moment is simple: the first time you see an opening you had not found yourself, that fits you and is still open. Everything about sign-up was redesigned to get people there faster.

The first version used a Google Form. It was the fastest way to launch, and it was costing us the aha moment:

• The first matches arrived one to two days later. Someone paid, filled in a form, and then waited for an email. The moment of highest intent was followed by silence.
• It could not ask the questions that matter most. Target roles, what you do not want and the companies you would love to work for were missing or buried in a free-text box. The biggest quality jumps came from exactly that data, and I was loading it by hand after the fact.
• The free-text field was misunderstood. “Tell us what your CV doesn’t say” was read as a career summary, not as “what are you looking for.” One person wrote about their Airbnb.
• The email used to pay was not the email people read. Two of the first four people I interviewed paid with a different address, so the onboarding sequence went to an inbox they never opened.
• Users called it “long and generic.”

I replaced it with a sign-up form on the site, built for one goal: get to the first relevant openings as fast as possible.

• Five short steps that work on a phone: emails (the one to receive Radar and, separately, the one you paid with), city and modality, target roles and what you do not want, languages, and CV plus LinkedIn PDF.
• Target roles from minute one, with suggestions from our own list of job titles, instead of me inferring them days later.
• Two separate fields instead of one ambiguous box: “What are you looking for now? This is what we use to search” and “What your CV doesn’t tell (optional).”
• The CV goes straight to our system and is deleted from the server once processed, instead of sitting in a Drive folder the pipeline could not even read.
• First matches on the same page, in about ten minutes. A task checks for new sign-ups every ten minutes, reads the CV, runs the matcher for that person only and shows the first openings while they are still on the page: “Looking for your first matches…” turns into real jobs.
• It works inside LinkedIn’s and Instagram’s in-app browsers, where many people arrive, with a fallback upload method and a WhatsApp exit if everything fails. A half-written form is saved in the browser so nothing is lost.

The time from paying to seeing a first relevant opening went from one or two days to about ten minutes. The first email still goes through my review before it is sent, but the person no longer waits a day to find out whether the product understands them.

What I learned on the feedback calls

From the start, Radar had a human channel. During the beta, testers answered with voice notes about every match. During the trial, day 2 of the onboarding offers 15 minutes with me: no script, no sales pitch, just “what are you looking for that your CV doesn’t say, and what did you think of what you received.” I did those calls myself, and they changed the product more than any metric.

What people value, and all of them said it: the curation (“not just anything arrives”), that it runs by itself every morning, the labels to decide quickly, My Radar and the tone. One person applied to a role from their second email. Another got three openings they had not found despite “looking under every rock.”

What hurt, and what changed because of it:

• “I don’t like this one” is never just taste. The beta voice notes broke down into four measurable dimensions: level of the role, the industry or domain it revolves around, how technical it is, and sales style (hunting new clients versus managing relationships). Each one became a rule in the matcher and a button in the email. When someone says a job does not fit, I first ask which of those four it is, and only then touch the score.
• The labels became four checks. People wanted to know why at a glance, so each opening now says Role, Level, Location and Language, each with a ✓ or a ~ and the caveat in words (“asks for less experience than yours”). Location answers the question every candidate in the region has: can I apply from my country?
• Emails were landing in Promotions or spam. Each email had about 45 links: a button per job plus seven feedback chips per card. I replaced the chips with one “Is this useful?” link per card that opens My Radar with the reasons, which cut the links to about 12.
• The payment email mismatch and the misunderstood free-text field came straight from these calls and shaped the new sign-up form.
• “I can do this with ChatGPT.” One user had built their own “job radar” in Claude and used it in parallel. They put it best themselves: with Claude they could not reach many portals, because they did not have access. That sentence became the positioning.
• What people asked for next: CV advice based on the gaps between their profile and the openings, and a way to ask questions inside Radar. Both are on the roadmap because someone asked on a call, not because I guessed.

The calls also produced the most useful testimonials on the landing page. When you ask people what they think and then visibly change the product, they want to tell others.

Decision one: score how much of the job is in your CV, not how good the job is

The first version compared word frequency. That is a bad signal in a CV: what matters is your latest experience, not how often a word appears.

The score now works like this. For each posting, I build its core: the terms that are much more frequent in that area than across the whole board, so “campaign, onboarding, pipeline” weigh in and “team, business, company” do not. Then I measure how much of that core your CV covers, with each term weighted by recency: 1.0 if it appears in your current role, 0.8 in the previous one, down to 0.2 if it only shows up in your education.

Role titles are not compared as strings. Two-column PDFs come back as things like “PARTNER FOR LATAM AND EUROPE Nationality Argentina COMPANY SPAIN.” Instead, I extract role words and map them to families with affinities: full-stack is close to back-end, back-end is not close to front-end, partnerships is close to marketing.

The score never reaches the user. It is our signal for ordering. What the person sees is the label and the reason.

Decision two: stop excluding, start layering

By early October the engine was a chain of exclusions, and the evaluation set was almost all “this should not appear” cases: 103 of 121. Every new rule “improved” the score by cutting more. The people paying were getting zero matches.

The fix was structural:

• Measure recall, not just precision. The evaluation set now includes “this must appear” cases taken from real feedback.
• Exclude only on explicit signals. Seniority is almost never in the title. Excluding on inferred seniority removed half of what reached that step. Now only a junior title or a stated range ending at two years or less excludes; everything else goes in with a note like “asks for less experience than you have.”
• Order by layers instead of returning empty. Each layer only runs if the previous one comes back empty after verification: exact or similar role from the last 30 days; then a broader role, flagged as such; then older postings that the scraper still sees live; then both. If the email reaches layer two, it says so: “nothing exact came up today.”

Precision still comes first. Anything doubtful does not go out. But “something honest, labeled Stretch, with the reason” beats silence.

Decision three: what you say you want beats your CV

The largest quality jumps did not come from tuning the score. They came from loading, by hand, the 15 to 60 role titles each person is actually targeting, plus the role families they do not want.

The CV says what you did. Your free-text answer, the jobs you strike out and what you reply by email say what you are looking for. A marketing person with a “Sales” title from 2019 kept receiving sales roles until the area started coming only from the two most recent titles, weighted 1.0, 0.7, 0.4.

The flip side: a single word in free text is not an intent. “Insights team” is not the Marketing area. “Mining and oil companies” is not a company name.

Decision four: nothing goes out unreviewed

Every email passes two gates.

The automatic one removes postings with broken links, from another country, repeated or already struck, and blocks the whole email if a link is empty or template text was left unfilled. One bad email costs more than a day without one.

The human one is me. Every person’s matches open with their full profile next to them: titles, how years were estimated, education, free text, target roles, excluded families, past votes. A check forces a job in even if a filter excluded it; a cross removes it, and if two or more people strike the same posting it becomes doubtful for everyone.

Every new sign-up is also simulated and reviewed before their first email. Of four sign-ups on one day in October, three were misread: a marketing profile receiving project roles, an IT service-delivery profile read as “operations,” a mid-level person bumped a level up. All three were caught in review, not by the customer.

Decision five: when there is no supply, say it

Sometimes the engine is not failing. Remote, Spanish only, open to Argentina, a niche coordination role: four postings in the entire corpus.

The honest response is not to loosen filters until something appears. The email shows what is limiting the results, how many openings there would be with English, another modality or another city, and I go find sources. Every company a person names in the sign-up form becomes a request to the board’s sourcing queue.

Before calibrating against a person, I measure how much supply exists for them. Some cities simply do not have enough senior openings for a daily email yet. That is a market fact, and treating it as a model bug would have wasted weeks.

Positioning: “I can do this for free with ChatGPT”

Three leads in one week said they did not need Radar because they already search with ChatGPT or Claude. One trial user showed me the system they had built in Claude. It was much weaker, but to them it was the same thing.

The answer was not “we are better than ChatGPT.” We use language models ourselves. The answer was to make the infrastructure visible:

• Coverage. A chat searches what Google indexed. Radar opens 9,600 company pages, 203 recruiting agencies and 79 portals every morning, including ATS systems a chat cannot browse.
• Cleanliness. About one in seven postings we see in a week has already closed by the time we verify it. Those never reach you.
• Judgment. Your CV is read for level, years, industries and languages, and every match says why, with a person reviewing before it goes out.

The funnel is the pitch: from about 4,300 new postings a day, to five for you. Every email now says how many of its matches were published in the last 24 hours, so the value shows up daily without a speech. The trial became a challenge: compare one week against your own setup. The most useful testimonial on the landing page comes from a user who had built their own search system with Claude and switched.

What broke in production

Real users find the bugs your tests do not:

• The novelty filter inverted silently. The digest only sent matches registered after the last send, but a brand new match is not registered yet at that point. After their first email, people received nothing ever again, with no error.
• In-app browsers are not browsers. Sign-ups from LinkedIn’s embedded browser failed to upload CVs. The form now retries, falls back to sending the file inside JSON, suggests opening it in Chrome or Safari, offers WhatsApp as a human exit, and reports every failure.
• A corporate antivirus opens every link in an email within seconds, voting for and against everything at once. Bursts of six or more clicks in 30 seconds are discarded.
• Gmail drops styles when you reply. All email styles are inline.
• A full hosting disk breaks unrelated things. Backups filled the quota: My Radar uploads failed, sign-up showed no matches, and the site lost its styles because the cache could not write minified CSS.
• What you emailed must keep existing. An “Is this useful?” link opened My Radar without the job, because the page had archived it. Everything sent and still open now always stays visible.

What it produced

• A paid product built in one week, tested with 8 real users, and used by 15 people in less than two weeks.
• A seven-day onboarding sequence with one ask per day, and a sign-up that cut the time to the first relevant opening from one or two days to about ten minutes.
• A sign-up that shows your first matches in about ten minutes, a daily email with explained labels and one-click feedback, and a private dashboard with everything else.
• A matching engine with recency-weighted scoring, role families, layered recall and explainable labels.
• An evaluation set of 196 real verdicts that every rule change has to keep or improve (175 pass today), on top of 1,447 tests shared with the board.
• A daily operation with one human decision point, a health panel that only alerts when there is something to do, tracked clicks and votes, and a win-back email for people who cancel.
• A positioning and landing page that turn the most common objection into the sales argument.

Lessons learned

Build on what you already have. Radar took a week because the hard part, 9,700 sources verified every day, already existed. The new product was a thin layer of judgment on top of a thick layer of data.

Time to value is a design decision. The Google Form was the fastest way to launch and the slowest way to reach the aha moment. Every hour between paying and seeing a first good match is an hour for doubt. Move the first result as close to the sign-up as you can.

Onboarding is not documentation. Seven emails that each ask for one action taught people the product and improved their matches at the same time. Explaining why a quiet day is normal prevented more churn than any feature.

Do the feedback calls yourself. Every important change, from the four checks to the new form to the positioning, came from 15-minute conversations. Users rarely tell you what to build, but they always tell you where it hurts.

Test with real people before you charge. Eight users and their voice notes shaped the product more than any metric. The labels, the reasons and the feedback buttons all came from them.

A system that only filters ends up returning nothing. If your evaluation set only has negative cases, every rule looks like progress. Measure recall, and when exact matching is not enough, order by layers instead of excluding, always labeled.

A signal that is not in the data cannot exclude. Inferred seniority, inferred language, inferred location: they go in as notes. Only explicit signals cut.

Absence of evidence is not evidence of absence. A CV that does not mention English does not mean the person cannot read it. Mark it, do not drop it.

Explainability before precision. Showing why something matched, which skills overlap, whether the level fits, does more for trust than a finer score.

The first email is the product. Review every new person before it goes out. The most expensive bugs were in how we read the person, not the job.

An alert that fires every day stops being read. Each alert has to name the action. A drop in matches after deliberately reorienting someone’s profile is not a problem.

When there is no supply, say so. Being honest about the market is a feature. Inventing matches is how you lose a subscriber.

Infrastructure is the moat, but only if people can see it. The pipeline was always the difference. It did not sell until the email itself showed it, every morning, in one line.