FoloUp: an open source voice interviewer wired to four hosted services

Four services, four API keys, one Next.js application

The README is organized as a setup checklist, and each step corresponds to a hosted service. Clerk handles authentication and organizations. Supabase stores the data. Retell AI manages the voice calls, including storage of the recordings. OpenAI generates the interview questions and analyzes the responses. That is the whole external surface, and it is worth noting that two of the four are billing meters you pay per use rather than flat subscriptions.

The environment template in the repository root makes the contract explicit. `.env.example` lists the Clerk variables `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` and `CLERK_SECRET_KEY`, the Supabase pair `NEXT_PUBLIC_SUPABASE_URL` and `NEXT_PUBLIC_SUPABASE_ANON_KEY`, plus `RETELL_API_KEY` and `OPENAI_API_KEY`. Five values to fill in, and the README is specific that the file must be `.env` and not `.env.local`, with no inverted commas around the keys.

Getting started is two commands:

git clone https://github.com/FoloUp/FoloUp.git

followed by copying the template. The README notes that free plans should be enough for Clerk and Supabase, that Retell provides free credits to start, and that the OpenAI usage would not be costly. It does not say the same for Retell at volume, which is the line item that matters if this ever runs for real hiring.

Multi-tenant by way of a Clerk organization

The Clerk setup is not a copy and paste of two keys. The README walks through creating an application, populating the environment file, and then navigating to the Organization Settings page to enable organizations, and finally creating an organization and inviting your own email address to it. That last step is the one that surprises people: without an organization membership, you log in to an app that has nowhere to put your data.

This is the tenancy model. A hiring tool has companies in it, not just users, and each company needs its own set of job descriptions, interview links and candidate results. Rather than building that with its own user table and permission checks, the app delegates it to Clerk organizations, so membership and access control come from a service that already handles invitations, sessions and identity.

The consequence for anyone reading the code is that the shape of the data model is partly defined outside the repository. The Supabase schema in `supabase_schema.sql` gives you the tables, but who can see which rows depends on Clerk organization membership, and the repository does not spell out that mapping in the documentation.

A SQL file instead of a migration system

Database setup is unusually direct. You create a Supabase project, open the SQL Editor, copy the SQL from `supabase_schema.sql`, run it to confirm the tables are created, and then paste the project URL and anon key into the environment file. There is no migration directory, no seed script, no schema versioning story described anywhere.

For a project at this stage that is a defensible tradeoff. A single file you can paste into an editor is easier to understand than a migration chain, and it makes the data model inspectable in one sitting. The cost shows up the moment the schema changes: existing deployments have to be told to re-run the file, and there is no record of what they have already applied.

The tree also carries a `supabase/` directory alongside `supabase_schema.sql`, which suggests the project keeps Supabase specific material there beyond the single schema file. The tree is short enough to read as a whole: `src/` for the application, `public/` for static assets, plus the usual Next.js configuration files and a `Makefile`.

A Dockerfile, a compose file, and a Vercel recommendation

Self hosting is documented as a recommendation rather than a full guide. The README recommends Vercel, and the repository carries a `Dockerfile` and a `docker-compose.yml` for anyone who would rather not.

The compose file is short and does one interesting thing, which is reading the port from an environment variable with a default:

services:
  foloup:
    build: .
    ports:
      - "${DOCKER_PORT:-3000}:3000"

The Dockerfile is a multi-stage Node 23 Alpine build with separate `deps`, `builder` and `runner` stages, so dependencies are installed once and the final image carries only `.next`, `node_modules`, `package.json` and `public`. It adds a non-root `nextjs` user before copying the built app, which is the kind of detail a container image should have and many do not.

The scripts in `package.json` are worth a glance because they explain the webpack flag. Development and build both pass `--webpack` explicitly, and the lint, format and check scripts all delegate to Biome.

Interview creation, shareable links, and scoring

The feature list describes the product in five lines. Interview creation generates tailored questions from any job description. One-click sharing produces a unique interview link to send to a candidate. AI voice interviews are described as conversational and adaptive to candidate responses, so the questions are not a fixed script read out loud. Smart analysis gives detailed insights and scores per response. A dashboard tracks candidate performance and overall statistics.

The adaptive part is the interesting technical claim, and it is the part the README does not detail. Generating questions from a job description is a straightforward model call. Conducting an interview that changes based on what the candidate just said requires a voice agent to observe a response, decide on a follow-up, and speak it, which is what Retell provides as a managed service. The README describes Retell as managing storage of recordings and providing a simple SDK to integrate with.

Dependency versions in `package.json` place this firmly in the Next.js app router era: `@clerk/nextjs` at version 6, Supabase JS 2, MUI and Radix components side by side, TanStack Query and Table for data, and Framer Motion for motion. There is a Railexpress carousel and a PDF parsing dependency in the list, which suggests resume or document handling is part of the intended product.

What the repository shows about its own direction

Two details in the README suggest the project is a base others build on rather than a finished service. There is a section titled Products built on top of FoloUp, with logos and links to three named companies, and a contact address offered for questions. A hobby project would not usually carry a list of downstream users.

At the same time, the repository metadata shows a modest footprint. It has 1,264 stars, 302 forks and 12 open issues, is licensed under MIT, and is written in TypeScript. The last push was on 2026-05-25, and there is no release history in the repository metadata, so there is no versioned line to track. The README points to a recorded walkthrough for the app rather than publishing screenshots with captions.

The topics give the honest one line summary: hiring, interviewing, recruiting, voice AI agents and webapp. Nothing about compliance, audit trails or candidate data retention appears anywhere in the setup instructions, which matters if you are evaluating it for real hiring rather than as a starting point.

Editorial conclusion

FoloUp is best read as a reference implementation of a category rather than a finished product. The interesting part is how narrow the code is: a Next.js front end, a Supabase schema you paste into an editor, a Clerk organization model for multi-tenant access, and two API calls out to Retell for voice and OpenAI for questions and analysis. You can read that whole pipeline in an afternoon, and the README even names companies that have built products on top of it. Set it up with the four free tiers, run one interview end to end, and you will know within a day whether your hiring process is the kind that suits an automated first pass.

Frequently asked questions

Official sources

1. FoloUp/FoloUp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README