I spent months building Rendure — a full-stack agentic resume tailoring pipeline. Next.js frontend, FastAPI backend, Celery workers, LangChain, LangFuse for observability, RenderCV for PDF generation, deployed at rendure.kaustubhsstuff.com. It worked. I used it. I'm shutting it down.
Last month I found career-ops by Santiago Ferreira — a Claude Code-native job search system with a Go-based TUI dashboard, portal scanners, batch evaluation, and an interview story bank. It does everything Rendure did, plus most of the job search workflow Rendure never touched. I forked it, plugged my own pipeline pieces into the parts that didn't fit me, and moved on.
This is a post about when to stop building your own thing.
What Rendure was for
I built Rendure because I was tired of manually tailoring resumes for every application. The QA step was the part I cared about most: I wanted the generated resume to be tested against the job description before I ever looked at it. My pipeline runs up to four iterations — generate, compare against the JD, identify gaps, regenerate — and only surfaces output that passes a bar I set.
The rest of Rendure was scaffolding around that QA loop. A web UI because "tools should have UIs." A Celery queue because "jobs should be async." LangFuse because "observability matters." Every piece defensible in isolation. None of it actually moved the needle on whether I got interviews.
What career-ops got right that I didn't
Career-ops is scoped differently. Instead of a hosted web app, it's a local tool that turns Claude Code into a command center — you paste a job URL and it evaluates fit, generates a tailored PDF, and tracks the application. The whole thing is markdown files, YAML config, and .mjs scripts the agent orchestrates. No server to run. No queue to maintain. No frontend to style.
More importantly, it handles the parts of the job search I kept telling myself I'd "add later":
- Portal scanning across Greenhouse, Ashby, Lever, and company pages
- Batch evaluation of dozens of listings in parallel
- An interview story bank that accumulates STAR responses across evaluations
- A TUI dashboard for browsing the pipeline without opening a file manager
- A scoring system that tells me when a role isn't worth applying to
Rendure would have taken me another three months to reach feature parity on any single one of those. Career-ops ships them all.
What I replaced in the fork
Two things didn't fit, so I swapped them.
The resume generation had no QA loop. Career-ops generates a tailored PDF in one shot — prompt the model, render the result. For my own search I want the four-iteration loop from Rendure: generate, compare to the JD, find gaps, regenerate, stop when it passes or hits the iteration cap. I pulled that pipeline out of Rendure and wired it into career-ops's resume mode. The agent calls my QA loop instead of the one-shot generator.
The PDF template wasn't ATS-friendly. Career-ops uses an HTML template rendered via Playwright with Space Grotesk and DM Sans — it looks great. It also has visual elements that trip some ATS parsers and a font stack that won't embed cleanly into every system. I'd already standardized on RenderCV (LaTeX-based, plain text output, ATS-tested) for Rendure, so I replaced the HTML + Playwright path with a RenderCV YAML pipeline. Same input (tailored resume content), different renderer.
Everything else — the scoring modes, the portal scanner, the batch runner, the dashboard — I kept. The fork is small and targeted.
The decision I kept avoiding
Rendure was a learning vehicle. I learned a lot building it: async orchestration, LLM observability, full-stack deployment, the real costs of running a service you don't need. That's valuable, and the code will stay on GitHub with a README that explains what it was and why I moved on.
But maintaining two tools that solve the same problem while I'm actively job searching is a tax on attention I can't afford to pay. Every bug in Rendure is time not spent applying. Every "I'll migrate that feature over to career-ops eventually" is a feature I don't have today.
The honest reframe: Rendure was my tool when nothing better existed for my workflow. Career-ops is better for my workflow now. Using it instead of my own thing isn't a failure of ambition — it's the right call.
What I'd tell anyone building their own version of something that already exists
Search harder before you build. I didn't find career-ops until I'd already built most of Rendure, and that's on me. "There's no tool that does this" is a claim I should have pressure-tested more before I wrote the first line of Next.js.
Build the thing that's actually yours. My QA loop and ATS-tested PDF pipeline were genuinely mine — opinionated decisions that reflect how I want my resumes to work. That's the part worth keeping. The Celery queue and the React UI were generic infrastructure I could have skipped.
Know when to swap vehicles. You can hold onto the parts of your work that matter without holding onto the whole system you built around them. The fork is the migration path: keep what's opinionated, drop what was scaffolding, run on someone else's foundation.
Rendure helped me get better at writing resumes. Career-ops helps me actually apply to jobs. That's the whole story.
Top comments (0)