The Resume Feature I Rebuilt Five Times: Lessons Learned

MockEvalio's resume feature didn't take long to build. It took five rebuilds to become something I was willing to call resume intelligence, and all five happened within about thirty-four hours.

The first version, shipped early afternoon on March 11, did one thing: it scored a resume against a job description. Upload a PDF, DOCX, or plain text file, extract the text, parse it into sections — skills, experience, education — and compare it semantically against a job description already sitting in the vector store from the day before. The score itself came out of a fixed formula: 0.4×keyword match + 0.2×experience match + 0.2×skill coverage + 0.2×format score. Four factors, weighted, added up to a single number.

That was the whole feature. It worked, it returned a score, and by the same evening it had already grown past what that first version did.

A few hours later, the scorer was wired into the rest of the product for real — resume upload and scoring backed by actual storage, scores cached in Redis, and an AI pass added to rewrite weak bullet points instead of just flagging them. A couple of hours after that, the resume score stopped being a standalone number. It became one input into a broader readiness score, folded in alongside interview performance and skill matching — the first sign that "how good is this resume" was really a smaller question sitting inside a bigger one.

By early evening the same day, the resume itself got restructured. No longer just text run through a formula, it was parsed into an actual document — a summary, an experience section, skills, projects, education, each one addressable on its own. The keyword comparison became a semantic one. Rewriting a bullet point stopped meaning "replace this text" and started returning something structured: the original line, the rewritten line, and what kind of improvement it represented.

The next night, the rewriter's output changed again — from prose the frontend had to parse and reformat, to structured JSON it could render directly, with PDF, DOCX, and JSON export built in. And less than an hour after that, the whole thing became a pipeline: one stage to find weak bullets, keywords, and formatting problems; a second stage to rewrite the flagged bullets in parallel, in action-verb, measurable-impact language; a third stage to produce a properly structured, ATS-optimized document with education included. What had started as a single formula was now a three-stage process with its own versioning and its own exports.

The formula from that first version — 0.4×keyword + 0.2×experience + 0.2×skillCoverage + 0.2×format — is still recognizable somewhere in what the pipeline eventually became. I know exactly what those four numbers were. What I don't have is a record of why those particular weights, and not some other split. If there was a reason beyond "this seemed like a reasonable place to start," it isn't in the commit history, and I'm not going to invent one now.

What I also can't establish is why the feature kept changing this fast. Five rebuilds in a day and a half could mean a staged plan, executed roughly in order. It could mean genuine iterative discovery — building the simplest version first specifically to find out what it was missing. Or it could mean reacting, revision by revision, to problems that only became visible once the previous version existed. The commit history doesn't tell me which one it was, and I don't want to claim more certainty about my own reasoning at the time than the evidence actually supports.

A working ATS score existed within hours of deciding to build one. Turning it into something I'd actually call resume intelligence took five more attempts and a day and a half. Whether that gap was the plan, or something I only discovered by rebuilding, isn't something I can answer just by reading the commits.