Build looked absurd under a recruiter deadline

A developer built a reusable career system using Cursor, an AI-powered code editor, after a Riot Games recruiter reached out with a short deadline. The system separates structured career facts from application-specific wording, allowing the developer to generate tailored resumes for different companies. The developer argues that AI lowered the cost of building custom software, shifting the build-versus-buy tradeoff for disposable artifacts like resumes.

Building a resume platform before replying to a recruiter sounded absurd. The rational move is an off-the-shelf resume builder. Implementation cost usually outweighs the benefit, especially when a reply is due in a few days. A Riot Games recruiter reached out while I was still preparing to return to the job market. Suddenly I needed a current resume to send back, and I had roughly two afternoons to produce one. My default assumption was simple: buy beats build . Use an existing tool. Ship a document. Move on. AI changed that calculation enough that I built a reusable career system instead. Under a short deadline, custom software is usually the wrong trade. You are not optimizing for reuse. You are optimizing for a PDF in someone's inbox. A resume builder gives you templates, export, and enough polish to look professional without inventing infrastructure. That was the economically rational stop line for most of my career. Build when the system will run for years. Buy or manually assemble when the artifact is disposable. I expected the same pattern here. I built a private facts → prose resume repository with Cursor. The idea is to separate career evidence from application wording: | Layer | Holds | Does not hold | |---|---|---| | Structured facts | Stable claims actions, outcomes, metrics, scope | Resume bullet phrasing | | Application config | Which facts to include, tone, theme | New career claims | | Generated output | Markdown and PDF resumes | Source of truth | Career claims live once in structured YAML. Each application selects, reorders, and rephrases them. npm run generate renders recruiter-facing prose. npm run pdf prints it. npm run check:ats runs structural ATS checks on the output. You do not need my private repo to apply the pattern. The useful split is structured facts on one side and disposable rendered artifacts on the other. Before generating a resume, the workflow researched the company and role, then used that context to decide which evidence from my career inventory belonged in the application. The system knew about far more career evidence than any one resume should contain. The inventory stayed put. What changed was which slice mattered. For a gaming company like Riot Games, the research made a university game-design award relevant enough to surface on a software engineering resume where it normally would not belong. The same run also produced a one-page and two-page resume plus a recruiter reply. A week later, I used the same career inventory for an AI product engineering company. The underlying evidence had not changed, but what mattered had. The workflow selected a different slice of it. The reuse I had been optimizing for was already real. Later it expanded past resumes into interview prep materials, a use I had not planned when the recruiter first wrote. Different company, different evidence selection. Different stage, different artifact altogether. The system that looked overbuilt for one reply kept finding uses. The repository did not begin with that model. It evolved through increasingly useful abstractions across the same short build window: The first workable version was not the last one. Because implementation and revision were cheap, I could keep moving instead of freezing at "good enough for tonight." Without that cost shift, the rational stopping point would probably have been a reusable template or a lightly parameterized document. Fine for one application. Weak as career infrastructure. That is the piece a resume builder does not give you: room to discover the right abstraction after the first one works. AI did not magically make build correct for every problem. It lowered two costs at once: Buying still wins when the problem is narrow, the tool fits, and you will not reuse the result. Building still loses when maintenance will crush you. What changed is the boundary. Problems that used to land firmly on the buy side can cross over when reuse matters and you can afford to iterate past the first design. This is not an argument that custom software always beats SaaS. I chose to build because the deadline still left room for something reusable. If the goal had been a single resume, buying an off-the-shelf builder would have been the faster path. The build path made sense here because: Cheap iteration on both implementation and revision is what made exploring these abstractions affordable. The same economics show up outside resumes: internal tooling, dashboards, documentation pipelines, code generators, personal workflow infrastructure. Anywhere the old math was "custom software is too expensive to build and revise ", the revise term got smaller. I suspect that generalizes beyond software engineering into knowledge work where bespoke systems used to lose to packaged tools on turnaround alone. Takeaway: AI moves the build-vs-buy threshold by cutting both implementation cost and the cost of changing your mind about architecture. When reuse matters and you can iterate in the same sprint, building a small internal system can become rational where buying would previously have won on cost and turnaround. If you'd like to see the same economics on a product I keep revising in public, try Codenames AI https://codenames-ai.com/?utm source=devto&utm medium=article&utm campaign=ai-changed-the-build-vs-buy-threshold&utm content=footer .