Flockara / applied AI product
Tailorbird.
Generation is easy. Trust is engineered.
What it does
Tailorbird helps job seekers create role-specific resumes without inventing experience or paying twice for the same work.
Why it matters
A resume needs to earn trust from the person sending it and remain readable by the systems receiving it.
What I owned
I owned the workflow, architecture, generation controls, cost decisions, testing, and production operation.
Conceptual architecture illustration. No production account or client data.
From the idea to the interface
01 / THE PROBLEM
Start with the constraint.
A generated resume is only useful if it is truthful, readable, and worth the cost of producing it. The hard part is the surrounding system: identity, job fit, duplicate work, validation, PDF rendering, and failure recovery.
I evolved a Streamlit prototype into a multi-user FastAPI application. Server-rendered HTMX and Alpine.js keep the interface light; Redis and arq move long-running work off the request path. SQLite stores account and workflow state.
02 / THE ARCHITECTURE
Under the hood.
- 01Source resume + job description
- 02Fit gate + duplicate check
- 03Claude generation · background worker
- 04Validate → PDF → delivery
A simplified view of the boundaries I designed.
03 / ENGINEERING DECISIONS
The details that matter.
Do not pay twice for the same work
I added two layers of duplicate detection: hashes collapse repeats inside a run, and an owner-specific fingerprint index recognizes previously delivered work. Failed jobs stay retryable.
A billed response is an asset
I found that a successful, billed response could still fail local parsing. I added a salvage path that preserves the raw output and usage context, so a parsing failure does not silently discard paid work.
Truth needs a code boundary
I made employers and certifications a programmatic boundary: if a credential is absent from the source resume, the validator rejects it. Other claims still need review; a prompt alone cannot guarantee truth.
A PDF must survive extraction
I found that a PDF could look right while its text extracted incorrectly. I fixed markup escaping and extraction problems, then checked both the visual document and what an ATS would read.
04 / TESTING & DELIVERY
Make the result accountable.
I validated the pipeline with network-isolated replays of stored results and checked the rendered PDFs as well as their extracted text. Cost experiments isolated stretch-match jobs as the main token driver, while a backfill audit found 16 duplicate charges that the new guards prevent. My original audit covered 108 resumes and 308 experience entries, with no invented employers, titles, or dates found in that sample.
I used Claude Code to accelerate implementation while owning the requirements, architecture, prompt and context design, debugging, acceptance criteria, validation, and release decisions.
05 / OUTCOME & LESSON
Treat model output as untrusted input. Reliability comes from the decisions made before, around, and after the call.
A self-hosted resume workflow with account separation, background processing, fit-scored PDFs, delivery, and explicit controls for cost and output quality.
Open Tailorbird ↗Evidence & provenance
Source reviewed: billed-response recovery, duplicate index, credential validation, PDF rendering, account routes, and tests. Historical replay and audit results are recorded in the original project materials; those runs were not repeated during portfolio preparation.