Building custom software to solve a two-afternoon problem sounded absurd.
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.
Normally that is an obvious buy decision. Under a short deadline 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.
Historically, I built when the reuse justified the setup cost. I bought or assembled manually when I only needed the artifact.
The same rule still applied. What had changed was the cost.
AI had lowered not only how much it cost to build the first version, but how much it cost to keep revising the architecture underneath it.
What I built instead
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 system did not start here
The repository did not begin with that model.
It evolved through increasingly useful abstractions across the same short build window:
- A single resume document
- A reusable resume template
- Career facts separated from prose
- Capabilities grouping related achievements
- Evidence entries inside each capability
- Application-specific selection over that inventory
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 was the advantage of the build path here: room to discover the right abstraction after the first one works.
Two costs moved, not one
AI did not magically make build correct for every problem.
It lowered two costs at once:
- Implementation cost: scaffolding the generator, themes, and checks stopped being a multi-week side project.
- Architectural iteration cost: revising the underlying model (facts vs capabilities vs application selection) stayed cheap enough to do in the same session.
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.
Buy was still faster for one send
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:
- The career inventory is the stable core.
- Research and role context drive application-specific selection.
- The same system produced multiple resume variants and a recruiter reply.
- It later expanded into interview prep materials.
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.
Top comments (0)