How many CV versions are worth keeping comes down to a small number rather than a growing pile: one base version that covers the work history, education and skills common to every role you are targeting, plus a handful of light variants, usually two or three, built for the distinct role types you are actually applying to, rather than a separate saved document for every single posting or every company name. Beyond that small number, a new variant usually adds more maintenance burden than it returns in relevance.
A practical ceiling: one base plus a small number of variants
Every additional saved variant is a document that has to be updated every time something changes on the base CV, a new role, a finished project, an updated skill, so the real cost of a version is not the space it takes up, it is the ongoing attention it demands to stay accurate. A base plus two or three variants, one per genuinely distinct role type, usually covers the range most active job seekers are actually applying across; a base plus five or six starts to blur into duplicates that differ from each other by very little, which is a sign that some of them should probably be merged back into one.
What each variant should actually differ on
A variant earns its own saved document when it differs from the base in the same ways applying to multiple jobs without sending the same CV everywhere already covers for grouping postings: a different summary line, a different emphasis in the skills section, a different order of bullet points, built around a genuinely different type of role rather than a genuinely different company. Two variants that differ only in which company name a candidate happens to be picturing while writing them, with no real difference in which content is emphasised, are not actually two different variants; they are the same variant duplicated for no functional reason.
When a variant has earned its place, and when it hasn't
A variant is worth keeping once it has actually been sent somewhere, or is genuinely queued to be sent to a specific type of role in the near future. A variant built speculatively, just in case a role like that comes up eventually, with no active application behind it, is usually better left unbuilt until an actual posting justifies it, since a speculative version tends to go stale exactly because nothing is prompting it to be kept current. If a role type stops being something you are actually applying to, the variant built for it has stopped earning its place too, whether or not it was ever formally retired.
Retiring a version instead of letting it pile up
A version that no longer matches an active job search is worth deleting rather than leaving untouched indefinitely, since a stale variant sitting alongside current ones adds confusion about which document is actually up to date the next time one needs updating or sending. Retiring a version is a small, deliberate step, checking it is genuinely inactive, then removing it, rather than something that happens automatically, and it is worth treating as part of the same light habit covered in keeping a CV updated between job searches, so the active set of versions stays small and current rather than accumulating old ones nobody is looking at anymore.
Keeping one version as the master record
Even with several active variants in play, one document is worth treating as the master record, the version every other variant's changes eventually get folded back into so the underlying facts, the dates, the roles, the achievements, stay in one place rather than drifting slightly differently across every variant. The base version described earlier is the natural candidate for this role, since every variant already derives from it; updating the master first and then propagating a change into whichever variants are still active is a more reliable habit than updating variants independently and hoping they stay in sync.
Illustrative example: a three-version set for one job seeker
Illustrative example. A backend engineer applying broadly keeps three documents: a base CV covering the full work history and core skills, a variant emphasising infrastructure and reliability work for platform-engineering postings, and a variant emphasising API design and integration work for product-engineering postings. Each variant differs from the base in its summary line and the order of a handful of bullets, not in the underlying facts, and the engineer retires the platform-engineering variant a few months later once that particular job search wraps up, leaving just the base and the one variant still in active use.
The account ceiling, and why it matters less than it sounds
A CVBuilderKit account can hold up to 25 saved CVs at once, and each version, whether it is the base or a variant, is saved as its own separate document rather than a duplicate created from a single source. In practice, a base plus two or three active variants uses only a small fraction of that ceiling, so the limit that matters day to day is not the account's own storage cap but the smaller, self-imposed one described above: keep the number of active versions small enough that every one of them can realistically stay current.
Build yours
Start from one base CV, add a variant only once a genuinely different role type justifies it, and retire one the same way once it stops being active. Build or update your base version in the builder.