HasteCV is my own product: an AI-assisted resume and cover-letter builder, live at hastecv.com. I built every layer of it solo. Django and Django REST Framework on the API, Celery and Redis for async generation and export jobs, Vue 3 with Tiptap on the front, Docker on Render, with a generation layer that speaks to both Anthropic and OpenAI.
The document model came first
A resume is two documents wearing one name. It is structured data (experience arrays, education, skills) that templates and exports need, and it is a visible page a person actually reads and edits. Most builders pick one and fake the other. HasteCV keeps both: every document carries structured fields plus a rich-text body, and every id is prefixed by type (cv_, cl_, note_) so any tool can route a document from the id alone, no type parameter required.
That decision looked like over-engineering until AI clients showed up. Then it became the product.
The MCP server
HasteCV ships an MCP server that exposes documents to AI clients like Claude Code: list, read, create, update, export, with schema discovery as its own tool so a client learns the exact field shapes instead of guessing at them. A few design calls I would defend in a review:
- Errors are values, not exceptions. A failed call returns a readable error object, because a model that can read the failure can usually recover from it. A raised exception just ends the conversation.
- Schema description is a tool. The client asks the API what a cover letter looks like before writing one. Self-describing beats documented.
- Archive over delete. The destructive path exists but the recoverable one is the default, because an AI client with write access deserves guardrails the same way an intern does.
- Arrays replace wholesale. Read, modify, write back. Partial array patching is where state bugs live.
Dogfooding, daily
I run my own job-application pipeline through this server from Claude Code: tailored CVs pushed in as structured documents, PDFs exported without opening a browser. The thing I learned building it is that making an API legible to a model is a design discipline, not a plumbing task. Small contracts, explicit schemas, recoverable failures. The instincts that make a component system usable by another engineer turn out to make an API usable by an AI, and that overlap is most of why I keep building in this space.