AI Platform That Turns Your Resume Into Proof that You Can Actually Code so Resume says "React developer." One proves it.
Every developer has been there. You spend 3 hours polishing your resume, listing every framework you've ever opened a tutorial for, and then a recruiter spends 6 seconds scanning it. Interviews test LeetCode algorithms you'll never use on the job. Nobody actually verifies if you can build things.
I got tired of that. So I built One an AI platform that parses your resume, generates a personalized Proof-of-Work assessment from your actual stack, gives you a real-time voice mentor, and builds a 6-month career roadmap from a conversation. All in one workspace.
What I Built
One is a full-stack AI developer career platform. Here's the core loop:
- Upload your resume PDF → GPT-4o extracts your real skills (not the company's skills, yours)
- Take a Proof-of-Work assessment → 27 auto-generated questions across MCQ, coding, system design, and workflow
- Talk to Keri → a voice AI mentor powered by OpenAI Realtime API that knows your scores and stack
- Get a 6-month roadmap → generated from your actual conversation with Keri, not a template
Tech stack:
- Next.js 16 (App Router, Turbopack)
- Supabase SSR for authentication
- OpenAI GPT-4o for resume parsing, chat, and roadmap generation
- OpenAI Realtime API (
gpt-4o-realtime-preview) over WebRTC for voice - Tailwind CSS v4 + shadcn/ui + Framer Motion
- Deployed on Vercel
What It Actually Does
- Parses resume PDFs and extracts only skills the candidate personally used ignores technologies listed in employer descriptions
- Generates exactly 27 questions: 20 MCQ + 3 coding challenges + 2 system design + 2 workflow questions, all tied to the candidate's actual projects
- Scores each skill area and renders a visual skill graph
- Opens a real-time voice session with Keri no audio round-tripping, sub-second response
- After the conversation, generates a structured 6-month learning roadmap with hours-per-month estimates and an active month marker
- Fully auth-gated with per-user data isolation no shared state between accounts
- Supports email signup, Google OAuth, and GitHub OAuth, all without email confirmation friction
Key Features
- Resume-aware question generation every question references the candidate's specific projects and stack
- Voice mentor with full context Keri reads your resume skills, test scores, and roadmap before speaking
- WebRTC voice, not REST — audio goes directly browser → OpenAI, the server is never in the audio path
- Roadmap from conversation talk to Keri, then one button generates your personalized plan
-
Zero email confirmation server-side admin API creates users with
email_confirm: true - Per-user localStorage isolation switching accounts clears previous user's data automatically
-
Route protection on every request
proxy.tsverifies Supabase session before any page renders - Non-resume detection if you upload a hostel form or invoice, One tells you instead of inventing skills
How I Built It
Resume Parsing: Getting GPT-4o to Stop Lying
The naive approach "here's a PDF, what are the skills?" doesn't work. GPT-4o will happily extract every technology mentioned in every job description the candidate ever worked near. That's not the candidate's skill set, that's their employer's stack.
I used OpenAI's Files API to upload the PDF, then hit gpt-4o with a two-step prompt:
const PROMPT = `You are analyzing a document to determine if it is a DEVELOPER/ENGINEER
technical resume and generate a personalized coding assessment.
STEP 1 — Is this a developer resume?
A valid developer resume MUST contain ALL of the following:
- Personal work experience (jobs, internships, freelance) OR personal projects built by the candidate
- At least 3 distinct programming languages, frameworks, libraries, or technical tools used BY THE CANDIDATE
If NOT a valid developer resume, return ONLY:
{ "not_resume": true, "skills": [], "title": "", "questions": [] }
STEP 2 — If valid, return ONLY:
{
"not_resume": false,
"skills": ["skill1", "skill2", ...],
"title": "TopSkill · SecondSkill",
"questions": [
{ "type": "mcq", "skill": "React", "q": "...", "opts": [...], "a": 0 },
{ "type": "coding", "skill": "JavaScript", "q": "...", "answer": "..." },
{ "type": "system-design", "skill": "System Design", "q": "...", "answer": "..." },
{ "type": "workflow", "skill": "Architecture", "q": "...", "answer": "..." }
]
}`;
Step 1 is a gate. If the document doesn't have personal work experience AND 3+ personal skills, it short-circuits and never generates questions. Step 2 has an explicit instruction to extract only skills the candidate personally used.
Then I added a server-side guard on top of the model's own judgment:
// Treat as not-a-resume if: model flagged it, too few skills, or no questions generated
if (parsed.not_resume || skills.length < 3 || questions.length < 5) {
return NextResponse.json({ not_resume: true, skills: [], title: "", questions: [] });
}
The model can lie. The guard catches it.
One more gotcha: OpenAI's response_format: { type: "json_object" } throws a 400 if the word "json" doesn't appear anywhere in your messages. Took me longer than I want to admit to figure that one out.
Voice AI: WebRTC in Next.js Without Losing Your Mind
Keri uses OpenAI's Realtime API for sub-second voice responses. The architecture matters here — you do not want your server in the audio path. That adds latency and cost. The right flow is:
Browser → (SDP offer) → Next.js server → OpenAI /v1/realtime
OpenAI → (SDP answer) → Next.js server → Browser
Browser ←→ OpenAI (direct WebRTC audio, server out of the loop)
The session endpoint creates a short-lived token:
// /api/realtime/session
const res = await fetch("https://api.openai.com/v1/realtime/sessions", {
method: "POST",
headers: {
Authorization: `Bearer ${key}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "gpt-4o-realtime-preview",
voice: "shimmer",
}),
});
The SDP endpoint forwards the browser's WebRTC offer to OpenAI and returns the answer:
// /api/realtime/sdp
const sdpOffer = await req.text();
const res = await fetch("https://api.openai.com/v1/realtime?model=gpt-realtime-2", {
method: "POST",
body: sdpOffer,
headers: {
Authorization: `Bearer ${key}`,
"Content-Type": "application/sdp",
},
});
const answerSdp = await res.text();
return new Response(answerSdp, { status: 200, headers: { "Content-Type": "application/sdp" } });
After the SDP handshake, the server is completely out of the audio path. The browser and OpenAI talk directly over WebRTC. That's why the latency is low — there's no proxy in the middle.
Keri's Context: A Mentor Who Knows You
The thing that makes Keri feel different from a generic chatbot is that she has real data about you injected into every conversation:
const ctxLines: string[] = [];
if (context.skills?.length) {
ctxLines.push(`Resume skills: ${context.skills.join(", ")}`);
}
if (context.skillScores?.length) {
const sorted = [...context.skillScores].sort((a, b) => b.v - a.v);
ctxLines.push(
`PoW test scores: ${sorted.map((s) => `${s.k} ${s.v}%`).join(", ")}`
);
}
if (context.roadmap?.length) {
const rm = context.roadmap.map((m) => {
const tag = m.active ? " ← CURRENT" : m.done ? " [done]" : "";
return `Month ${m.month} · ${m.title}: ${m.topics.join(", ")}${tag}`;
}).join("\n");
ctxLines.push(`6-month roadmap:\n${rm}`);
}
Every message to GPT-4o carries the user's actual resume skills, their exact test scores sorted by performance, and their current roadmap status. When you ask "what should I work on?", Keri doesn't guess — she looks at your lowest score and your next roadmap month and gives you a specific answer.
Auth: Skipping Email Confirmation Without Disabling Security
Supabase's default signup flow sends a confirmation email before the user can log in. That's terrible UX for an assessment tool where you want people in the app immediately.
Supabase used to have a UI toggle for this. They removed it. The workaround is the admin API:
// /api/auth/register
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.SUPABASE_SERVICE_ROLE_KEY!
);
const { data, error } = await supabase.auth.admin.createUser({
email,
password,
email_confirm: true, // skip verification entirely
user_metadata: { full_name: name, organization: org ?? "" },
});
The register page calls this server-side endpoint, then immediately signs in the user with signInWithPassword. No email. No waiting. Just in.
Per-User Data Isolation
One stores resume data, test scores, and roadmap state in localStorage. The problem: if user A logs in after user B on the same browser, they'd see B's data.
The fix is a user ID sentinel key:
const storedUserId = localStorage.getItem("one-current-user");
if (storedUserId !== currentUserId) {
// Different user — clear everything
const keysToRemove = Object.keys(localStorage).filter((k) => k.startsWith("one-"));
keysToRemove.forEach((k) => localStorage.removeItem(k));
localStorage.setItem("one-current-user", currentUserId);
}
And to make sure no React state from the previous user survives, the entire dashboard remounts using a key prop tied to the user ID:
<main key={userId || "anon"}>
{/* VoiceAgentPage, ChatbotPage, ResumePage all remount on user change */}
</main>
A React key change forces a full unmount → remount cycle. No stale state, no data bleed between accounts.
Route Protection: Zero Flash of Dashboard
The most important UX requirement: unauthenticated users cannot see a single frame of the dashboard. Not even for 200ms.
Next.js 16 with Turbopack uses proxy.ts (not middleware.ts — having both breaks the build with a conflict error). Every request hits this file first:
const { data: { user } } = await supabase.auth.getUser();
if (!user && !isPublic) {
const url = request.nextUrl.clone();
url.pathname = "/login";
url.searchParams.set("next", pathname);
return NextResponse.redirect(url);
}
getUser() verifies the JWT with Supabase's servers — it's not just reading a cookie, it's an actual session check. If there's no valid session, the redirect happens before Next.js renders a single byte of the page. The authChecked state in the dashboard is a second layer: the component renders a black screen until the client-side session check confirms.
Roadmap Generation From a Conversation
After talking to Keri, one button generates a structured 6-month learning plan. The model gets the full conversation history and produces a typed JSON object:
const ROADMAP_PROMPT = `You are analyzing a mentoring conversation to generate a
personalized 6-month learning roadmap with working hours.
Return ONLY:
{
"months": [
{
"month": 1,
"title": "Short title (2-4 words)",
"focus": "One-line focus statement",
"topics": ["topic1", "topic2", "topic3"],
"hours": 40,
"done": false,
"active": false
}
]
}
Rules:
- Exactly 6 months, current → 6 months ahead
- Tailor to what the user mentioned: stack, goals, struggles
- "active": true for the one month to focus on RIGHT NOW (only one)
- "done": true for skills already mastered`;
The roadmap uses gpt-4o-mini (cheaper, fast enough for structured JSON) with response_format: { type: "json_object" }. The conversation history is passed directly as messages — no summarization, just the full context.
Lessons Learned
The hardest bugs are prompt bugs, not code bugs.
The resume parser would occasionally invent plausible-looking skills for a PDF that was clearly not a resume. A hostel admission form returned "JavaScript, Python, React" because those words appeared somewhere in the document. The fix wasn't adding more validation code — it was restructuring the prompt to evaluate the document type before attempting skill extraction. A two-step prompt is slower but dramatically more accurate.
Next.js 16 Turbopack has quirks that aren't documented yet.
Having both middleware.ts and proxy.ts in the project root causes a hard build error: "Both middleware.ts and proxy.ts detected." The error message is clear enough, but there's almost nothing about this online because the convention is new. When you hit an undocumented framework error, check the framework version first — the answer is almost always a breaking change from a recent release.
WebRTC in a serverless environment means your server does almost nothing.
The intuition is: real-time audio needs a persistent server. In practice, with OpenAI's Realtime API, your server only handles the SDP handshake (two HTTP requests). Everything after that is peer-to-peer. Serverless functions are completely fine for this pattern.
response_format: { type: "json_object" } will silently break if you don't say "json."
OpenAI's API throws a 400 Bad Request with the message 'messages' must contain the word 'json' if you use JSON mode without the word "json" appearing somewhere in your prompt. After a refactor removed that word from my prompt text, the endpoint broke in production with an error I'd never seen before. Add "Return only a JSON object" to every prompt that uses JSON mode — not just to satisfy the API, but as good practice.
Force-push rewrites git history but GitHub's contributor cache is slow.
After rewriting all commits to remove Co-Authored-By trailers and force-pushing, the Contributors panel on GitHub still showed the old co-author for hours. The code was fixed; the cache just hadn't expired. GitHub's contributor computation runs on a delay — nothing to do but wait.
What's Next
One is live at onee-eight.vercel.app. The core loop works end-to-end. What I'm building next:
- Shareable PoW cards — a public URL with your verified skill scores you can attach to job applications instead of a resume
- Employer view — companies post a role, One surfaces candidates ranked by actual test performance in that stack
- Progressive retesting — take the same assessment monthly and track skill growth over time on the skill graph
- Team assessments — evaluate an entire engineering team and surface collective gaps by skill area
The core insight hasn't changed: resumes are promises. Proof-of-Work is evidence. The goal is to make the evidence the default.
Built with Next.js 16, Supabase, OpenAI GPT-4o, OpenAI Realtime API, Tailwind CSS v4, and shadcn/ui.
— Arish singh
Top comments (0)