Resume Builder: a resume tool built around my own workflow
Built a structured resume editor so the same data can move between clean templates, previews, and PDF exports without fighting Word.
Why I built it
I know resume builders already exist. That was never the interesting part.
I wanted something that worked closer to how I think about resumes: keep the data structured once, switch between clean templates, check the result, and export a PDF without spending half the evening fighting Word.
AI made that realistic. I did not need to wait for the perfect existing tool or bend my workflow around someone else's product. I could build a version for myself, with the small details that kept annoying me.

Data before layout
The main decision was to treat the resume as structured data before treating it as a document.
That means personal details, intro text, experience, education, skills, saved bullets, and saved roles live as editable fields. Templates can change around that data without forcing me to rebuild the whole resume.
It sounds basic, because it is. But it removes a lot of the normal document mess. A role can be reused. A contact set can be loaded into another tab. A bullet can be saved once and inserted somewhere else later.

Clean templates only
There are probably a hundred thousand resume templates out there. I did not want to compete with that.
The templates in this tool are meant to stay clean and basic. The goal is a resume that reads well, looks consistent, and does not break when the content changes.
I added enough choice to make the tool useful: classic, modern, compact, ATS strict, and a few other restrained layouts. I also added structure presets for different resume situations, like a standard CV, a career pivot, or an early career version.
The boundary matters. If the tool tries to support every possible visual style, the product becomes harder to use and the data model gets pulled in too many directions.

Preview decisions
One decision I kept coming back to was preview rendering.
The most accurate option would be to render the final PDF all the time. For a personal tool, that probably would not melt anything. I am not running a high traffic SaaS product from this.
But I still wanted to think about it properly. The editor uses a fast HTML preview while I am writing, then a rendered PDF preview when the resume is close to finished. The final download still uses the PDF renderer.
That split keeps editing responsive and saves expensive rendering for the moment where accuracy matters. It is a small product decision, but those are the decisions I built this project to practise.


What I kept out
The project got better when I said no to things.
I did not want it to become a job tracker, a CRM, or a general document editor. I also did not want AI rewriting to be the centre of the product. The point is to manage and reuse my own content, not have the tool quietly change my voice.
Import is handled carefully for the same reason. Pasted resume text can create a draft tab, but it is still something to review. Copied PDF text is messy. Dates break. Headings move. The tool should help start the work, not pretend the import is automatically correct.
What I built
The current version can keep several resume tabs open, archive old ones, save versions, reuse personal details, store whole experience entries, collect bullets in a Bullet Bank, handle cover letters, switch templates, tune spacing, check PDFs, back up the workspace as JSON, import pasted resume text, guide new users, and sync signed-in workspaces without mixing accounts.
That sounds like a lot when written out. In the product, I tried to keep it pointed at one job: create clean resumes from the same underlying data without fighting the document every time.
What I learned
This was a useful project because it was ordinary.
No one needs another dramatic claim about AI changing everything. But AI did make it possible for me to build a familiar tool around my own habits, then keep improving it as I noticed small problems.
That is where most of the learning sat. Not in the idea itself, but in the decisions: where accuracy matters, where speed matters, what should be reusable, what should stay local, what belongs in scope, and what would only make the product heavier.
The logo
I also made a small logo for the system.
The document shape made sense for a tool about turning structured data into a finished resume. The landscape inside it is mostly because I liked the mark and wanted the product to feel a bit more like its own thing, even if it is only a personal tool.