{"slug": "build-looked-absurd-under-a-recruiter-deadline", "title": "Build looked absurd under a recruiter deadline", "summary": "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.", "body_md": "Building a resume platform before replying to a recruiter sounded absurd.\n\nThe 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.\n\nA 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.\n\nMy default assumption was simple: **buy beats build**. Use an existing tool. Ship a document. Move on.\n\nAI changed that calculation enough that I built a reusable career system instead.\n\nUnder a short deadline, custom software is usually the wrong trade.\n\nYou 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.\n\nThat 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.\n\nI expected the same pattern here.\n\nI built a private **facts → prose** resume repository with Cursor.\n\nThe idea is to separate career evidence from application wording:\n\n| Layer | Holds | Does not hold |\n|---|---|---|\n| Structured facts | Stable claims (actions, outcomes, metrics, scope) | Resume bullet phrasing |\n| Application config | Which facts to include, tone, theme | New career claims |\n| Generated output | Markdown and PDF resumes | Source of truth |\n\nCareer claims live once in structured YAML. Each application selects, reorders, and rephrases them. `npm run generate`\n\nrenders recruiter-facing prose. `npm run pdf`\n\nprints it. `npm run check:ats`\n\nruns structural ATS checks on the output.\n\nYou 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.\n\nBefore 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.\n\nFor 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.\n\nA 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.\n\nLater 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.\n\nThe repository did not begin with that model.\n\nIt evolved through increasingly useful abstractions across the same short build window:\n\nThe 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.\"\n\nWithout 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.\n\nThat is the piece a resume builder does not give you: room to discover the right abstraction after the first one works.\n\nAI did not magically make **build** correct for every problem.\n\nIt lowered two costs at once:\n\nBuying 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.\n\nWhat 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.\n\nThis 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.\n\nThe build path made sense here because:\n\nCheap iteration on both implementation and revision is what made exploring these abstractions affordable.\n\nThe 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.\n\nI suspect that generalizes beyond software engineering into knowledge work where bespoke systems used to lose to packaged tools on turnaround alone.\n\n**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.\n\nIf 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).", "url": "https://wpnews.pro/news/build-looked-absurd-under-a-recruiter-deadline", "canonical_source": "https://dev.to/michaeltruong/build-looked-absurd-under-a-recruiter-deadline-1145", "published_at": "2026-08-13 06:39:39+00:00", "updated_at": "2026-08-13 07:16:08.695440+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-products"], "entities": ["Riot Games", "Cursor"], "alternates": {"html": "https://wpnews.pro/news/build-looked-absurd-under-a-recruiter-deadline", "markdown": "https://wpnews.pro/news/build-looked-absurd-under-a-recruiter-deadline.md", "text": "https://wpnews.pro/news/build-looked-absurd-under-a-recruiter-deadline.txt", "jsonld": "https://wpnews.pro/news/build-looked-absurd-under-a-recruiter-deadline.jsonld"}}