I Built NextProof Because Resume Match Scores Weren't Enough.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Let's be honest. Job descriptions can feel like someone combined five different roles into one and called it an entry-level position. 💀

Then comes the resume-editing ritual.

You read the job description, look at your resume, rearrange a few things, add some keywords, and hope the recruiter sees the connection.

But here's the thing , matching keywords isn't the same as understanding whether your experience actually demonstrates what a role needs.

And sometimes, you might already have the experience. Your resume just isn't making that obvious.

That's why I built NextProof.

NextProof is an AI-powered resume analysis tool that compares your resume with a job description and helps you understand the relationship between the two.

Instead of stopping at a generic match score, it breaks the analysis into an overall assessment, strengths, gaps, and actionable next steps.

The idea is simple: help you understand what your resume demonstrates, where evidence might be missing, and what you can work on next.

Because there's a difference between not having a skill and not showing evidence of that skill on your resume.

I wanted to build something that takes that difference seriously.

Demo

Live: https://nextproof.onrender.com/

Upload a PDF or DOCX resume, paste a job description, and run an analysis. You can then explore the assessment, strengths, gaps, and suggested next steps.

The application is deployed on Render, with server-side API routes handling the analysis and feedback flows.

Code

GitHub: NextProof repository

Tech stack: Next.js · JavaScript · Tailwind CSS · Gemma · Google Gen AI SDK · Supabase · Render

How I Built It

Here's the high-level flow:

Resume (PDF / DOCX) + Job Description
                 |
                 v
        Validate the inputs
                 |
                 v
        Extract resume text
                 |
                 v
        Send context to Gemma
                 |
                 v
       Parse and validate output
                 |
                 v
        Structured analysis
                 |
       +---------+----------+
       |         |          |
       v         v          v
  Assessment  Strengths    Gaps
                            |
                            v
                        Next steps

          Feedback --> Supabase

The frontend is built with Next.js and JavaScript. The analysis API route handles file validation, text extraction, and communication with the model.

For document processing, I used pdf-parse for PDF resumes and mammoth for DOCX files. Both formats need to be converted into usable text before the analysis can begin.

The application uses the Google Gen AI SDK to access hosted Gemma inference. The API key stays on the server instead of being exposed in the browser.

The model's response is parsed and validated before being returned to the frontend. The results interface then presents the analysis through separate sections rather than making users dig through one giant block of generated text.

I also built a feedback flow backed by Supabase, allowing users to share their thoughts on the usefulness and accuracy of the analysis.

Finally, I deployed the application as a Next.js web service on Render, so the frontend and server-side API routes can run together.

Why Gemma?

The part I wanted to explore was how an open-weight model could help turn two pieces of text—a resume and a job description—into a structured analysis that someone could actually use.

A job description contains requirements. A resume contains a candidate's description of their experience. Connecting the two requires more than looking for identical words; it requires interpreting context and producing feedback that makes sense to the user.

That's the role Gemma plays in NextProof.

The model receives the extracted resume text and the job description as context and generates the analysis that powers the results experience.

The surrounding application is responsible for everything that makes this usable as a product: accepting files, validating inputs, extracting text, handling inference failures, validating the returned structure, and presenting the results.

Gemma provides the language understanding; the engineering around it turns that capability into a usable workflow.

I'm particularly interested in open-weight models because they give developers more room to experiment with how AI is integrated into products. You're not limited to thinking about AI as a feature that sits behind a button. You can make decisions about model selection, inference, deployment, and how the rest of your system handles its output.

For NextProof, that meant treating the model as one component in a larger application rather than assuming that a successful API call was the entire product.

Why I Chose Hosted Inference Instead of Running Gemma Locally

I did consider running a model locally through Ollama.

But that introduced another setup step and a model download of around 1.5 GB before I could focus on the actual product experience.

Given the challenge timeline, I had a choice: spend more time setting up local inference, or use hosted Gemma inference and concentrate on getting the complete application working.

I chose the latter.

That let me spend my time on the parts that needed to come together for NextProof to be usable: document extraction, input validation, structured results, error handling, and the complete journey from resume upload to feedback.

There is a trade-off, though.

NextProof currently depends on a hosted inference service. Gemma isn't running entirely on the user's device, and the analysis requires an internet connection and an available inference endpoint.

It also means the application must account for provider errors, latency, and the costs or usage limits associated with hosted inference.

Local inference could offer different advantages, including more control over the inference environment and the possibility of processing text without sending it to an external model service. But it would also introduce model-download, hardware, and setup considerations.

For this version, I prioritised getting the complete product working over adding another inference mode.

That was a scope decision, not a claim that hosted inference is always better.

The Decisions Behind the Build

I deliberately left authentication out of the current version.

The main question I wanted to explore was whether AI could help developers understand the relationship between their resume and a job description. Sign-up and login flows wouldn't answer that question.

Authentication would also mean taking on more than a login screen: session management, account handling, and decisions about how user data should be associated with an account.

For this version, I chose to prioritise the complete resume-analysis journey over building those additional systems before validating the core experience.

That doesn't mean authentication would never make sense. If NextProof grows to support saved analyses, personal history, or persistent user accounts, those features would need to be designed alongside appropriate data-handling and privacy decisions.

For now, I wanted the core experience to work before expanding the product around it.

Why define input limits?

A resume analyser accepts files, extracts text, and sends that text through an inference pipeline. Without explicit boundaries, an unusually large document or job description can make requests slower, more expensive, or less reliable.

So I added limits to make the current implementation more predictable.

Input	Limit
Uploaded resume	5 MB
Pasted job description	30,000 characters
Extracted resume text	40,000 characters

Each limit serves a different purpose.

The file-size limit bounds the uploaded document. The job-description limit constrains the pasted input. The extracted-text limit catches documents whose extracted content is too large for the intended processing scope.

The application also checks file types and whether useful text was extracted before sending the request for analysis.

These limits aren't magic numbers that guarantee accuracy, security, or perfect performance. They're explicit engineering guardrails that help control input size and keep the current workflow within a defined scope.

They can be revisited as I test more resumes, different document formats, and longer job descriptions.

I wanted NextProof to do more than work for one ideal example. Defining what it accepts, what it rejects, and how it handles failures is part of building the product.

Where This Could Go Next

There are a few directions I'd like to explore:

• Better ways to connect each finding to the evidence in a resume and the relevant job requirement.
• Evaluation against a broader set of real-world resumes and job descriptions.
• More user feedback to understand where the analysis is helpful, inaccurate, or confusing.
• Reconsidering authentication and saved analyses if there's a clear reason to introduce persistent user accounts.
• Exploring local inference if it makes sense for privacy, cost, and the experience I want to provide.

I'd rather let actual usage and testing guide these decisions than add features just because they sound impressive on a roadmap.

Why Open Innovation Matters Here

For me, the value of open-weight AI isn't simply that a model can be downloaded or that its weights are available.

It's the room it creates for developers to experiment, understand the trade-offs, and build products around models they can choose to use and adapt.

In NextProof, Gemma is a central part of the analysis pipeline. It gives me a way to explore how open-weight AI can be applied to a practical problem, while the rest of the application handles the engineering required to make that capability usable.

The hosted setup also makes the current trade-off clear: I get to focus on the product workflow, but I depend on an external inference service. A local implementation could change that balance, but it would bring its own constraints.

There isn't one approach that's right for every product. What matters is understanding what the choice gives you, what it costs you, and whether it makes sense for the people you're building for.

That's what I wanted to explore with NextProof.

Can This Become a Side Hustle?

The problem NextProof addresses is connected to a real, recurring activity: applying for jobs and trying to understand how your experience fits a role.

A future version could explore a paid tier for more detailed analysis, saved reports, or additional workflows for job seekers. But those are possibilities, not validated business results.

I haven't established willingness to pay yet, and I don't want to pretend otherwise.

Before introducing pricing, I'd want to understand whether people find the analysis useful enough to return to it, which recommendations they trust, and what they would actually pay for.

For now, the live application is a starting point for testing the idea and learning from real users.

Final Thoughts

I keep coming back to one question: how do we build AI tools that help people make better decisions instead of simply giving them another score to worry about?

Job searching already involves enough uncertainty. You don't always know whether you're missing a skill, underselling your experience, or failing to make the connection obvious.

I wanted to build something that helps people examine that uncertainty more carefully.

NextProof is my attempt at that: a working product that uses Gemma to help turn resume and job-description text into a more structured, actionable analysis.

It's live, it has clear limitations, and there's still a lot I want to learn from people using it.

sooo yeah, that's NextProof!!

if you're curious, give it a try and let me know what you think. I'd genuinely love to hear what works, what doesn't, and what you'd change.

try it out: https://nextproof.onrender.com/

wanna peek at the code? GitHub repository link

and if you do try it, pls come back and tell me how it went hehe. thank you for reading this farrr!! ✨