One resume, or a version for each role
One base, a few named variants, not fifty files
Keep one base resume that holds everything: every role, every bullet you have ever written, unfiltered. Then keep a small number of named variants, two or three at most, one per genuinely different kind of role you are pursuing. What you should not keep is a new file for every single application, because that system works for the first ten applications and then quietly falls apart.
The failure mode is familiar to anyone who has run a search for more than a month. Week one, every resume gets a careful pass and a save. Week four, there are eleven files named things like "resume_final2," "resume_v3_useThis," and "resume_updated_reallyfinal." Nobody remembers which one went to which company, and a recruiter writing back to ask for an updated copy turns into a search through a downloads folder for a file you are no longer sure you can stand behind.
What a base resume is for
The base resume is not something you send. It is raw material: every bullet you have ever written about every job you have held, including the ones that only apply to a narrow slice of postings. Nothing gets cut from the base, ever. When you tailor for a specific posting, as described in tailoring a resume without rewriting it, you are working from a copy of the base, not editing the base itself, so the full set of bullets is still there the next time a different posting needs a different one promoted to the top.
When variants earn their own file
A variant is worth creating when you are applying to roles that differ in kind, not just in employer. Someone applying to both "senior product manager, platform" and "senior product manager, growth" is not tailoring the same base into two shapes fifteen minutes apart, they are applying to two different jobs that happen to share a title. In that case, build two named variants once: "resume_pm_platform" and "resume_pm_growth," each with its own top block of reordered and renamed bullets. From there, tailor lightly from whichever variant is the closer match for each new posting. That turns a fifteen-minute tailoring pass into a five-minute one for most applications, because the heavy lifting already happened once per variant instead of once per posting.
Two or three variants is a ceiling worth respecting. A fourth variant usually means the roles are not actually different enough to justify a separate file, and the search is drifting back toward the eleven-file problem with slightly better naming.
A worked example: building the second variant
Say your base resume has six roles. For a platform PM variant, roles two and four, the ones with the most engineering-adjacent scope, get their full bullet lists promoted to the top of the experience section and rewritten to lead with the technical tradeoffs you owned. Roles one, three, five, and six keep a shorter, one- or two-bullet treatment, because they are real but not the center of the argument this variant is making. For a growth PM variant, the same six roles appear in the same order chronologically, since work history order does not change, but roles one and three, the ones with acquisition and experimentation work, get the expanded treatment instead, and roles two and four shrink down. Building both variants once takes perhaps forty minutes total. Tailoring from either variant for a specific posting afterward still takes the usual ten to fifteen.
What happens when one resume tries to serve both roles
Try to build a single resume that serves both a platform search and a growth search at once, and the likely result is a resume that leads with neither. Promoting both storylines to the top pushes everything else down, and the top of the page ends up making a blended case that is not sharp for either audience. A reader evaluating for a platform-heavy role sees acquisition bullets ahead of the platform bullets and reads the candidate as growth focused; a reader evaluating for growth sees the opposite. Two variants avoid that dilution entirely, because each one is allowed to lead with its own story instead of splitting the difference between two.
A naming convention that survives week four
Whatever you name your files, tie the name to the variant, not the company. The company changes every time; the variant does not. Something like "LastName_PM_Platform" or "LastName_PM_Growth" tells you at a glance which base you tailored from, months after you have forgotten the details of any one application. That naming pairs cleanly with whatever system you use to remember what you actually sent where. If you are not tracking applications anywhere yet, tracking applications without a spreadsheet covers the smallest version of that system that still holds up under real volume.
The real cost of too many versions is drift, not clutter
The hidden cost of an uncontrolled version system is not the mess of file names, it is drift between copies. You fix a typo in the header of one file and forget to fix it in the other four. A stronger version of your third bullet lands in the variant you used two weeks ago and never makes it back into the one you are using this week, so you keep sending the weaker line without noticing. Two or three tracked variants stay current because there are few enough of them to actually maintain in one sitting; eleven never do.
If application volume itself is what is driving the file sprawl, the underlying question of how many applications a week actually makes sense is worth answering directly; see how many jobs to apply to in a week. A search running at five applications a week can keep three variants current with a five-minute check-in each Sunday. A search running at twenty a week cannot, and the honest fix at that volume is usually fewer, better-chosen variants rather than more careful tracking of more of them.
iapplyai.app keeps your base resume on file and builds a tailored version for each posting it scores as a real match against it, so the variant problem above never turns into eleven mystery files on your desktop. The free tier covers two complete applications, then it is a fixed term pass that expires on its own, with no automatic renewal. What a pass costs.
