Should I vibe code
Build a structured resume and cover-letter workspace with templates and PDF export
Your two-column layout looks great to a human and parses as one scrambled sentence to the system that screens you.
?
Their verdict, the Premium (monthly) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
One person's employment history, rendered to a PDF, on their own machine. There is no stranger's data here, no money, no regulator and no uptime anybody else depends on — the worst outcome is that you spend a Saturday on layout instead of on applications. The homemade version is genuinely competitive, and better in one specific way: your CV becomes structured data you own rather than a document you reformat by hand for every role. The one thing worth taking seriously is that the reader you are optimising for is often not a person. Absolutely-positioned text boxes and a two-column layout look immaculate to you and come out of an applicant tracking system's parser as one long scrambled sentence, which is a failure you will never see.
What actually breaks
not "if". the specific failures.
- PDF text order, which is not visual order — a two-column layout built from absolute positions extracts as the left column interleaved with the right
- Fonts that were never embedded, so the recruiter's viewer substitutes something else and your careful one-page layout becomes a page and a half
- Pagination in general: a job title that wraps to a second line on somebody else's renderer pushes a section head to the bottom of page one, alone
- Dates and locale — a resume that renders 03/04/2024 to a reader who parses it as April, and a headless Chrome instance running in UTC
- The data model, which starts as one flat document and needs to be a list of roles with structured bullets the first time you want a targeted variant
- Headless-Chrome-to-PDF as a dependency, which is a hundred megabytes of browser that breaks on the next major version and produces subtly different metrics than your screen preview
Is that you?
the verdict is a default, not a law
- It is your own CV, on your own machine, exporting a file you keep
- The source of truth is structured data — JSON or YAML — and the template is just a renderer over it
- You check the exported PDF by copying the text out of it before you send it anywhere
- You would be equally happy with the output if the project disappeared tomorrow
- Other people upload their CVs to it, at which point you are holding strangers' addresses, phone numbers and employment history
- It publishes a personal site or a public link by default, because a full CV on an indexable URL is a phone number and an address you cannot take back
- You are relying on generated bullet points to describe work you did not do
- The only copy of your history lives in the app rather than in a file you back up
If you build it anyway
the checklist, then the prompt that enforces it
- Keep the CV as structured data — JSON Resume is a fine schema and already has renderers — with the template as a pure function over it. Variants become data, not copies.
- Test the export the way a parser reads it: run pdftotext over your own output and read what comes back. If it is scrambled, the layout is the bug.
- Embed fonts in the PDF and pin the renderer version. A CV that reflows on somebody else's machine is a CV you did not proofread.
- Single column, real text, no text inside images, and no critical content in headers or footers. Everything else is decoration.
- If you ever add a public link, put a noindex header on it and expire it — a permanent indexed page with your address on it is the only lasting mistake available here.
- Write the export before the editor. The file you send is the product; the UI is convenience.
I am building a personal resume builder for my own CV: structured data, templates, PDF export. This is low-risk, so keep it that way — the failure mode is a document that looks right and machine-reads as noise. Push back if I drift toward hosting other people's data. 1. Data first. My CV is a JSON or YAML file on disk with a documented schema (JSON Resume is fine). Templates are pure renderers over it. No database is the source of truth, and no proprietary format. 2. Build export before the editor, and verify it by running pdftotext over the result and printing the extracted text. If the column order is wrong, fix the layout — do not tell me it looks fine in the preview. 3. Default template is a single column with real selectable text. No text inside images, no critical content in the header or footer, no tables used for layout. If I ask for a two-column design, tell me what it does to an applicant tracking system's parser first. 4. Embed every font in the PDF and pin the renderer version. Print the embedded-font list after each export. 5. Dates render from ISO values in a fixed locale, and the renderer runs in a pinned timezone. A CV that shows a different month on someone else's machine is silent and expensive. 6. Targeted variants are data, not duplicates: one base file plus an overlay that hides or reorders entries. Never copy the whole CV to change a line. 7. Keep it local. If I ask for accounts and uploads, stop and say that the moment other people's employment history is in the database this stops being a Saturday project and starts being personal data I am responsible for. 8. If I ask for a public URL for the CV, add noindex and an expiry by default, and say plainly that an indexed page with my home address and phone number is the one thing here I cannot take back. 9. Out of scope, and say so rather than half-building it: cover-letter generation, job tracking and anything that scores my CV against a job ad.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If you are actively job hunting and want the ATS scoring, the template library and the cover-letter tooling in one place, $19 for a month — or $43 for a year on their annual term — costs less than the Saturday. Buy it for the month you are applying, and keep your CV in a file either way so you are not locked into anybody's editor.
$19/mo is cheaper than your weekend.
There is almost nothing to exit. If the CV is a JSON Resume file and the template renders from it, the project dying costs you a build script — the same file feeds a dozen open-source renderers, and the PDFs you already exported are still PDFs. The version that traps you is the one where the history only exists inside your app's editor state.
Very active open-source resume builder with structured data, templates and PDF export.
The open schema and toolchain that turns a CV into a file many renderers already understand.
Questions
Is the ATS parsing worry real, or resume-industry folklore?
The screening scores are marketing; the parsing is not. Applicant tracking systems really do extract text from your PDF into fields, and a layout built from absolutely-positioned boxes really does come out in the wrong order. You can check it yourself in ten seconds: run pdftotext over your export, or just select-all and paste into a text editor. Whatever you see is roughly what the parser sees.
Why is this SHIP IT when a CV is full of personal data?
Because it is one person's personal data and that person is you, on your machine, in a file you already control. Sensitivity is only half of the picture — the other half is who gets hurt, and here nobody does. Add uploads for other people and the entry moves several bands in an afternoon.
What is the single thing worth getting right on day one?
The schema. Everything else is a template you will rewrite twice anyway, but if roles, dates and bullets are structured from the start, a targeted variant is a filter and not a copy-paste — and copy-pasted CVs are how the wrong job title ends up in the version you sent.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your resume renders beautifully in Chrome. The parser reading it sees one column of interleaved nonsense.
Ask a model for achievement bullets and it will invent the metric, because metrics are what good bullets have.
Comparing your CV to a job ad is text analysis on two documents you already own.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice