Resume Builder: structured content and reliable PDF exports

I built a personal CV editor that separates reusable content from document layout. It uses a fast HTML preview during editing and a rendered PDF check before final export.

Most of the work involved in maintaining a CV is not writing everything from scratch. It is selecting relevant content, adjusting emphasis and keeping the finished document consistent.

Traditional document editors combine content and layout. Small changes can create formatting work elsewhere. Dates move, sections split badly and content has to be copied between different versions.

I wanted the underlying information to remain stable while the final document could change around it.

The central design decision was to treat the CV as structured data before treating it as a document.

Personal details, summaries, employment history, education, skills, saved roles and reusable bullet points are stored separately from the final layout. A template decides how that information is presented, but changing the template does not change the underlying content.

This makes reuse practical. I can save a role once, select it for another CV and adjust it without starting again. Individual bullet points can sit in a Bullet Bank instead of being copied between old files.

The data model places some boundaries on the templates. That is intentional. Supporting every possible document layout would make both the editor and the content structure harder to use.

The editor needed to show changes quickly while I was writing, but the final PDF also needed predictable pagination. Those requirements are not identical.

The HTML preview updates immediately in the browser, but it does not always paginate exactly like the final PDF renderer. Most of the time the result is very close. Near a page boundary, however, a CV that appears to fit on two pages in the live preview can become three pages when rendered as a PDF.

The most accurate alternative would be to generate a new PDF after every edit. That would reduce uncertainty, but it would also slow the interface, add latency and repeatedly invoke server-side rendering on Vercel while the document was still changing.

I chose a two-stage model:

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 rendered check.

This accepts a small amount of temporary uncertainty during editing in exchange for a faster interface and fewer unnecessary PDF renders. Accuracy is available when it matters without slowing every edit.

The product is not intended to be a general document editor, job tracker or recruitment platform. Its purpose is narrower: manage reusable CV content and turn it into a clean final document.

The templates are restrained rather than decorative. Import creates a draft that still requires review because pasted and extracted document content is rarely reliable enough to accept without checking.

These boundaries make the tool less flexible than a general editor, but more coherent for the workflow it supports.

The application supports multiple CV tabs, archived versions, reusable personal details, saved experience entries and a Bullet Bank.

It also includes cover letters, template switching, spacing controls, PDF checks, JSON backups, pasted-text imports and signed-in workspace synchronisation.

The useful part of the project is the work across several boundaries: structured data and document layout, immediate feedback and exact rendering, flexibility and a manageable data model, local browser state and signed-in persistence, convenient import and trustworthy content, useful functionality and unnecessary scope.

I use the tool repeatedly for my own CVs. That continued use exposes small workflow problems and gives me a practical basis for deciding what to improve and what to leave out.

The result is a focused tool built around one real workflow, including the compromises that workflow requires.