How much is your MVP, really?Get an estimate
2MUCHCOFFEEGet a quote

An AI hiring platform,
from voice to shortlist

  • Case study

Developers build a profile by talking for five minutes instead of writing a CV. Recruiters describe the role they need in plain English and get back a ranked shortlist. We designed and built both sides, and the code is public.

Book a 30-min review
The AI matching screen: a recruiter has typed a role in plain English and the assistant is returning ranked candidates, each with a match score and the reason it picked them.
What it is
STFH, a hiring marketplace for developers and the people hiring them
Our role
The entire product, in-house: both apps, the AI, the infrastructure
Status
Built and running end to end, from voice onboarding to ranked shortlist
How to check it
The repositories are public, so every feature below can be read as code

Both sides of it

  • The developer video feed: a portrait video card with a placeholder silhouette, with the developer's name, role, location and tech stack over the video, and a rail of save, GitHub, LinkedIn, email and profile actions beside it.
    The feed. Developers introduce themselves on video, one card at a time, with save and contact actions alongside.
  • The voice onboarding screen, on question three of five, recording an answer with a recording timer bar and a stop button.
    Onboarding. Five questions, answered out loud, with a way out to the manual form at any point.
  • The developer browse screen: a search field, seniority and availability filters, and a grid of developer cards with location, seniority, tech badges and a short bio.
    Browsing. The same pool searched by hand, with filters for seniority and availability.

Want one of these for your own product? Book a 30-min review

Hiring developers breaks in three places

None of these are AI problems. They are product problems, and they are why the product works the way it does.

  1. A CV is a bad way to judge an engineer

    It is a document written to get past filters, so it fills up with the words a filter looks for and leaves out the things that tell you whether someone is right for your team.

  2. Nobody wants to fill in the profile

    Marketplaces lose people at the form. The profile stays half-finished, and a half-finished profile never shows up in anybody's search.

  3. Searching for skills finds the word, not the person

    Filter for React and you get a thousand people in no useful order. Everything you actually meant, the seniority, the timezone, the kind of product, never reaches the results.

How it works

  1. A developer talks for five minutes

    Five questions, answered out loud. Things like which technologies they work with day to day, and what kind of work they want next.

  2. They check the profile it wrote

    The answers come back as a filled-in profile. The developer fixes anything wrong and approves it. Nothing is saved before they do.

  3. A recruiter describes the role

    In ordinary language, including the parts no dropdown covers.

  4. A shortlist comes back, with reasons

    Ranked candidates, each with why they are on the list, and a shortlist to save the ones worth a conversation.

What a developer gets

  • A profile built from five spoken answers, with a written form for anyone who would rather type
  • A review step where they see every field before it is saved, and can change any of it
  • A short intro video on their profile, plus a photo
  • Role, seniority, location, availability, and the tech they actually work with
  • Work history and certifications, each editable on its own
  • GitHub, LinkedIn and personal site links, and full control to edit or delete the account later

What a recruiter gets

  • A chat where they describe the role instead of assembling filters
  • Ranked candidates with the reason each one was matched
  • Search that reads intent, running alongside the hard filters that genuinely are yes or no
  • A browsable feed of developer profiles with filters, tech badges, and full profile pages
  • A live view of the search working through the pool, rather than a loading spinner
  • A shortlist to save, review, and clear as they go

The parts that were not obvious

Three product problems that shaped the build. The engineering behind each is written up separately, for anyone who wants that level.

Turning five minutes of talking into something publishable

People restart sentences, correct themselves, and bury the useful fact in a story. Getting from that to a clean profile is genuinely hard, so we did not pretend otherwise: the system writes a first draft and a person approves it. That is why the profile is worth publishing and why nobody has to write it.

Search that understands intent without going vague

Meaning-based search finds the right person for a description no filter could express, and on its own it will also happily return someone who is unavailable or in the wrong country. Both run together, so intent decides the ranking and the hard constraints still hold.

Keeping results current when everyone edits their own profile

The moment someone updates their profile, search knows an old version of them, and nothing anywhere reports an error. So every edit marks that person for reindexing and the system tracks how many are currently out of date, which makes search quality something you can watch rather than something a user tells you about.

Read the code

Everything above is in public repositories, and reading them is the fastest way to check any claim on this page. The engineering decisions behind the hard parts are being written up separately.

The backend, in full devMatch-backend-fastapi

What it proves

One product covering most of what a production AI build actually demands, from capturing audio in a browser through to a ranked shortlist a recruiter can act on.

  • Voice and audio handled end to end, from recording in the browser to usable structured data
  • AI that fills things in for people without being trusted to save them
  • Search that ranks on meaning, over records that change every day
  • An assistant that uses tools, finishes, and shows its work while it runs
  • Video upload and processing that never blocks someone signing up
  • Two full applications, one for each side of a marketplace, plus accounts and access

Building something like this? Talk to the engineers who built it.

Book a 30-min review

The stack

  • Python
  • FastAPI
  • PostgreSQL
  • pgvector
  • Celery
  • FFmpeg
  • faster-whisper
  • Anthropic Claude
  • OpenAI
  • Next.js
  • React
  • Auth0

Questions

Does the AI decide who gets hired?

No. It finds candidates, puts them in order, and says why each one is on the list. A person reads that and decides. The same rule runs through the whole product: it fills things in and a human approves them, including on the developer’s own profile, where nothing is saved until they have checked it.

How is this different from searching a CV database?

A CV database matches the words someone wrote to get past filters. Here a recruiter describes the role in ordinary language, and that description is matched against what people actually do, alongside the constraints that genuinely are yes or no, like availability and location. What comes back is a short ranked list with reasons instead of a thousand rows.

Why ask developers to talk instead of filling in a form?

Because the form is where marketplaces lose people. Five minutes of talking produces far more than anyone types into a text box, and it moves the work from the person to the product: it writes the profile and they only correct it. Anyone who would rather type still can.

How do you stop it inventing things about a candidate?

By never letting it save anything. What it produces is a draft the developer reviews field by field before it becomes their profile. It can still mishear a company name or a framework, and the review step is where that gets caught.

Could this be built on our own candidate data?

The pieces travel better than the product does. Voice or document intake with a human approving the result, search that ranks on meaning over records that change constantly, and an assistant that returns a reasoned shortlist are all reusable. What changes per company is the data, which constraints are non-negotiable, and what counts as a good match, and that is the part worth spending discovery on.

Related

Other projects

Sweden’s 10M+ downloads fitness appFitnessSwedenSweden’s 10M+ downloads fitness appMaintain a healthy lifestyle with no time and no money.Product Hunt's SaaS Product of the YearSaaSProduct Hunt's SaaS Product of the YearCentralize all your apps in one single place.Normative: sustainability reportingSustainabilityNormative: sustainability reportingSolution for the fast transition to a sustainable society.

Let's build yours

We built this one end to end, and the code is public so you can check the work before you talk to us. Tell us what you're building and we'll show you what production-grade looks like for it.
<?xml version="1.0" encoding="UTF-8"?>