Resume Builder, structured content and reliable PDF exports

The short version

The problem

Keeping a CV current is mostly selecting and reshaping content, and normal editors mix content with layout.

What I did

Built an editor that stores CV content as structured data, separate from the final document layout.

What it was worth

In production. Every CV in my own job search comes out of it, and a few friends use it too.

The call

Fast preview while writing, exact PDF check at the end. Accuracy when it matters, speed the rest of the time.

Most of the work in keeping a CV current is not writing. It is choosing what to include, shifting the emphasis, and keeping the finished document consistent.

A normal document editor mixes the content with the layout. A small change makes formatting work somewhere else. Dates move, a section splits across a page, and content gets copied by hand between versions.

I wanted the information to stay put while the document changed around it.

Like the other builds, this one was written by Claude and Codex. The data model, the scope, the trade-offs and the testing are mine.

The main decision was to treat the CV as data first and a document second.

Personal details, summaries, employment history, education, skills, saved roles and reusable bullet points are stored apart from the layout. A template decides how they are shown, and swapping the template changes nothing underneath.

So a role saved once can go into the next CV and be adjusted there, and a bullet written once sits in the Bullet Bank instead of being dug out of an old file.

The data model limits what a template can do, on purpose. Supporting every layout would make both the editor and the content harder to use.

The editor had to show changes quickly while I was writing, and the final PDF had to paginate predictably. Those two pull in different directions.

The HTML preview updates at once, but it does not paginate exactly like the PDF renderer. Most of the time it is very close. Near a page boundary, a CV that fits on two pages in the preview can come out as three in the PDF.

The accurate answer would be a new PDF after every edit. That would also slow the editor down and hit server side rendering on Vercel over and over while the document was still changing.

So there are two stages.

1. A fast HTML preview while writing and restructuring the content.
2. A rendered PDF check when the document is close to finished.

The final download uses the same PDF pipeline as the check.

That accepts a little uncertainty while editing in return for a faster editor and fewer renders. Accuracy is there when it matters, and it does not slow every edit.

It is not a general document editor, a job tracker or a recruitment platform. It keeps reusable CV content and turns it into a clean document, and that is all.

The templates are plain by design. Import creates a draft that still needs reading, because pasted and extracted text is rarely clean enough to trust unread.

That makes it less flexible than a general editor, and easier to use for the one job it does.

Multiple CV tabs, archived versions, reusable personal details, saved experience entries and a Bullet Bank.

Also cover letters, template switching, spacing controls, PDF checks, JSON backups, pasted text import and a signed in workspace that syncs.

Most of the decisions in it are trade-offs between two things I wanted. Immediate feedback against exact rendering. Flexible templates against a data model I can keep in my head. Local browser state against signed in persistence. A convenient import against content I can trust. Picking a side each time, and saying which, is the product work.

I use it for every CV in my own job search. That keeps turning up small workflow problems, and gives me something better than opinion for deciding what to improve and what to leave alone.