The problem: collecting opportunities is easier than acting on them
I built Career Pipeline around a personal goal: turn relevant job requirements into focused engineering practice, explain the work in English, and use the resulting evidence in applications.
A saved posting is only an input. A useful outcome is a decision: apply with existing evidence, investigate eligibility, improve one missing capability, or move on. The application supports that decision without treating a skill score as a prediction of getting hired.
The project is a single-owner application. This case study describes the implementation reviewed in September 2026; it does not establish production availability, deployed database configuration, or an improvement in hiring outcomes. Personal job notes and account connections remain private.
The workflow I built
- Send a job posting to Telegram as text, a link, an image, or a PDF.
- Extract a structured draft and review the source, requirements, and location eligibility.
- Choose one active mission tied to relevant postings.
- Record engineering, English, or distribution evidence.
- Track applications and use actual feedback to decide what to do next.
A mission includes a specific gap, a real problem, a completion criterion, and a next action. A database constraint limits the application to one active mission. The intention is to keep attention on finishing useful work.
This is not a requirement to study before every application. Existing evidence may already be sufficient; a posting can also be unsuitable because of geography, timing, or compensation.
Ingestion: accept the input, then process it
The ingestion path separates a short webhook request from slower extraction:
Telegram
→ authenticated webhook
→ PostgreSQL ingestion ledger
→ QStash message containing an ingestion ID
→ worker claims an attempt
→ source snapshot and structured extraction
→ validated jobs committed in a database transaction
The ledger gives each Telegram update a durable identity. Workers claim a time-limited lease and an attempt number. The final database operation checks the attempt before committing jobs, preventing an older attempt from overwriting a newer one.
QStash carries the ingestion ID rather than the original file. Text can be replayed from a stored source snapshot. Images and PDFs still depend on the Telegram file reference, so they do not have the same replay guarantee.
Transient extraction failures can be retried. Invalid output or unavailable source content is recorded for review rather than silently treated as a successful posting.
This design addresses repeated delivery of the same Telegram update. Forwarding the same vacancy again creates another update and can still create duplicate postings. Cross-posting deduplication is a separate problem.
AI prepares a draft; the owner makes the decision
Gemini receives an output schema, and Zod validates the parsed result. This checks structure and required fields; it does not prove that the extraction correctly interpreted the source.
Requirements distinguish required, preferred, and unknown. Explicit alternatives can be represented as one OR group. Classified requirements include a supporting quote, which the owner still needs to check.
Location eligibility is separate. A posting saying “remote” does not automatically permit working from Indonesia. Ambiguity stays unknown until the source or a recruiter resolves it.
The coverage calculation uses explicit skill aliases and evidence reviewed by the owner. It measures which stated requirements have a linked piece of evidence. It does not measure proficiency, the quality of that evidence, or interview probability.
Keeping the tool small enough to use
I chose Next.js and PostgreSQL for the dashboard and workflow, with Supabase authentication and owner-scoped reads. Server-side owner checks protect application operations, while database policies provide another access boundary.
Google Calendar is optional and uses a dedicated calendar for scheduled sessions. The application stores its connection details and calendar identity; event times remain in Calendar. A scheduled session is a plan, while a completed artifact is evidence.
These choices have a cost: several hosted services, quotas, credentials, and failure paths need attention. A personal tool does not need enterprise scale, but it still needs a usable recovery path and a way to export data.
How it connects to my other projects
Pocket CFO addresses repetitive financial input. Career Pipeline addresses repetitive career administration. Both use structured extraction, but the data and decisions are different. Financial records, job notes, and public portfolio content stay in their own applications.
Project Argos is a place to explore delivery, ordering, and processing behavior. A focused experiment there can become engineering evidence for a relevant career mission.
This portfolio is the publishing surface: it explains selected work and its decisions. Its stable article URLs can be recorded as evidence in Career Pipeline, then used in an application or technical conversation.
That connection currently uses links and deliberate review. There is no automatic database sync or automatic publication of private notes. Evidence attached to a mission and evidence attached to a skill also remain separate records in the application.
What still needs work
The September review found that 11 of 42 existing matching tests failed because the tests still expected older matching behavior. The active coverage rules need tests of their own, including alternatives and evidence that has not been reviewed.
The edit-review API also writes the review and mission state separately. Unlike creating a review through the transactional function, an edit can leave inconsistent state if its second write fails. Editing historical reviews needs a clear policy before it can safely change a mission's current decision.
Further verification should exercise duplicate deliveries, expired worker leases, extraction failures, database errors, and backup restoration. The design should earn reliability claims through these checks.
What would make the project successful?
The measure is whether the workflow helps produce and use evidence: a reviewed opportunity, a focused action, an inspectable result, an English explanation, and an application or conversation.
The next product decision should follow actual use. If recording work takes more time than acting on it, the right improvement may be fewer fields. If applications stall despite strong evidence, another technical feature may not address the real bottleneck.
For my professional background and related work, see my public résumé.