I turned my job search into a product that remembers how I work.

What shipped: a web app, a local CLI, a company-board scanner, an explainable scoring model, a Markdown career record, a 42-tool MCP server, an employer posting and payment flow, a documented npm package, a design system, and a product site.

• As of September 2026: 356 company boards on my own watchlist, and approximately 25,000 postings fetched, deduplicated and scored per full run. A new profile starts with a registry of 304 boards.
• No TekJobs account. The record is Markdown on the user's machine.
• A person between preparation and submission. TekJobs drafts; it never sends.

Every screen of the running app on this page shows the repository's sample profile: Jordan Example, fourteen postings at companies that do not exist.

The problem

Job seekers do not lack listings. They lack continuity.

What shapes a good search is scattered across job boards, browser tabs, resumes, email threads, application forms, spreadsheets, private notes and conversations with AI. Every tool sees one fragment, so the job seeker explains again and again who they are, what they want, what they have already tried, and why earlier roles were turned down.

Most job products add another feed to check. I wanted a system that remembers the search, built on five principles:

1. The user owns the record.
2. A recommendation explains itself.
3. The system reduces decisions. It is not another infinite feed.
4. AI can research, organize and prepare. The user decides and submits.
5. Models and interfaces can change without erasing the history of the search.

The rest of this page is those five principles, one decision at a time.

Product decisions

From an inventory to a daily decision

The first model was a large, filterable table of postings. It made the breadth of the data visible, and it did nothing for the hardest part of the workflow: deciding where to spend limited time.

The model changed from here are all the jobs, search and filter them to here are the strongest decisions to make today. That produced Today: a bounded queue of the highest-ranked roles, best fit first, with one decision per row, Shortlist or Pass. Applications already started and follow-ups stay in view, and the page shows what skipping costs: how many postings closed before anyone looked. Unreviewed roles wait in Jobs. Finding and deciding became two modes.

Scoring as evidence, not a verdict

A match score easily becomes an unexplained judgment. In TekJobs every point traces back to a line in criteria the user wrote: title terms, seniority words, description terms, remote and location rules, a pay floor with a stretch band beneath it, recency, and hard exclusions.

The job sheet at the top of this page is that score in the product: it opens beside the list, and the score is a sum you can read, one signal per line. The score answers is this worth my attention today? It does not try to answer should I take this job?

Files before platform

The durable record is not the interface. Profile, criteria, job records, decisions, application history, people and drafts are Markdown in a folder the user chooses. The web app is one view of it; Obsidian, Git, scripts, an agent and interfaces that do not exist yet read the same files.

This is the note behind the job sheet above, trimmed:

---
type: job
status: interviewing
company: "Meridian Pay"
title: "Staff Design Engineer"
score: 137
weights: 3e895160
salary: "$225k–$275k"
pay_band: floor
---

## Why it matched
- title +40: design engineer
- seniority +10 (staff)
- description +29: design system, react, typescript, storybook, accessibility, tokens
- remote +15
- pay range tops out at $275k, at or above floor (+10, +8 for 75k above)
- posted 1d ago (+25)

## Status log
- 2026-09-05 — new → **reviewing** (via app)
- 2026-09-07 — reviewing → **applying** (via app)
- 2026-09-12 — applying → **applied** (via app)
- 2026-09-19 — applied → **interviewing** (via app)

## Application
- **Resume variant:** Design Engineer (Staff)
- **Applied on:** 2026-09-12
- **Risks:** No payroll domain experience; say so, and point at fintech at Acme.

The scanner preserves user-authored content and updates only listing state and system-managed metadata. What a user builds up over weeks stays theirs, and does not end up locked inside another hosted service.

AI with a stopping point

TekJobs uses AI where context and synthesis help: the onboarding interview, structuring criteria, explaining matches, researching a company, preparing truthful resume variants, drafting cover letters and answers, and reading optional email signals. It stops before submission on purpose.

I wanted the leverage without giving up authorship. Drafts are checked against the resume of record: a figure, date or bullet that is not on the real resume gets flagged, and so do stock phrases and placeholders. The packet counts the required fields that are filled, and says plainly that full boxes do not make a good application.

Design system

Density without noise

TekJobs holds tables, scores, filters, statuses, forms, timelines, notes and system feedback. The visual system had to carry dense operational information without turning into a generic enterprise dashboard: a dark working environment in forest greens, Bricolage Grotesque headings over Hanken Grotesk body, Azeret Mono for every number, one lime accent used as a signal, hairline rows instead of boxed tables, semantic color only for status and attention, and no shadows or gradients. The aim was a serious personal instrument, calm under a lot of information.

A score, a status, a decision and a warning should not look interchangeable. Scores are numbers, because they are weighted prioritization. Statuses are words, because they are workflow state. Decisions are explicit actions, Shortlist and Pass. Warnings use color only when the user has to act. Metadata is quieter, and system activity is monospace.

Part of the component set, the parts the product screens above use. Sample rows use fictional company names.

The same patterns carry the employer side. The app is built on Zengin, and its design-system check runs before every release.

From mockup to production

I treated the mockups as hypotheses about how the workflow should behave. Using TekJobs in my own active search showed where the interface asked for too much attention, where statuses were ambiguous, and where operational information competed with decisions. The mockups came from that search, so their company names are replaced with fictional ones.

The inventory became a decision queue. More information did not create more clarity; the product needed a smaller surface for deciding.

A number became a set of reasons. A number without an explanation asks for trust the system has not earned.

Tracking became distinct states. A status should say what the user can do next, not only what happened.

How it works

1. Build the profile. The user's own agent runs an onboarding interview over MCP, starting from the resume, and writes the profile and the criteria as notes. The Criteria page edits them afterwards and previews what a change would do before it is saved.
2. Scan. A morning task fetches the configured boards, normalizes and deduplicates the postings, and scores each one.
3. Decide. Today, as above.
4. Prepare. The job sheet holds the research, the fit and the packet, as above.
5. Track. Pipeline holds committed work; Overview answers whether the search is working, from each note's packet.

Criteria: the scoring rules as fields, with the raw JSON one tab over.

Overview on the sample profile. The numbers are only as true as the record.

The employer side

An employer gives the role, the location model, the pay range, the application method, the description, and matching terms, with a panel beside the form that explains how TekJobs will read the post. One Stripe checkout, $49 for 30 days, and the posting becomes one more source in every user's morning scan, scored against their own criteria like any company board. The flow asks only for what affects the outcome, keeps structured signals apart from promotional copy, and never hands an employer a list of who saw the post.

Post a job. The form sits behind the sign-in on the right.

Built for agents, not for one model

TekJobs exposes 42 MCP tools. A compatible agent can check onboarding, read the criteria, run scans, find jobs, explain matches, update records and prepare drafts. TekJobs does not require a model API key. It works through the signed-in AI client the user already runs, whether that is Claude Code, Codex, Cursor or Claude Desktop, and because the record is the files, switching clients changes nothing about the search.

Agent access. One command or one JSON block, and the page lists what a session does, in order.

From personal tool to public product

Publishing the repository was the easy part. The system had to make sense to someone who did not build it: a first-run path tested the way a stranger meets it, a fictional sample profile written by the product's own code, install docs and MCP setup for each client, clear data and privacy boundaries, a product site with terms and a privacy policy, releases cut from commit messages and published through npm's Trusted Publishing, contribution and security docs, and recovery states for a signed-out CLI, a board that moved or a failed fetch.

The design question changed from can I operate this system? to can someone who did not build it understand it, trust it, and recover it?

tekjobs.timurtek.com, the public front door.

Evidence

I built and ran TekJobs during my own job search: evaluating roles, tracking applications, managing screens and interviews, preparing material, and keeping the decisions around each opportunity. It did not replace the work of looking for a job. It made that work coherent, inspectable and reusable.

What I learned

The value is not the job feed. Listings are everywhere. What sets a search apart is the context around them: what the user wants, what they rejected, what they applied to, and what deserves attention now.

Explainability is a product feature. A score is only useful when the user can understand it and argue with it. Showing the signals turned the recommendation into the start of a conversation.

Dogfooding changes the product model. Using TekJobs in a real search exposed problems static mockups did not. The most important redesign was not visual. It was the move from a searchable inventory to a bounded daily decision system.

What comes next

• Make first-time setup easier across the supported agents.
• Make source health, and the effect of a criteria change on the ranking, easier to see.
• Learn from external users, and document the workflows that repeat.

This is the product work I am drawn to: a messy human workflow, an interface that reduces decisions, an AI layer with explicit boundaries, a design system that has to survive real expansion, and infrastructure that stays understandable after the demo ends. TekJobs is all of it in one system that I use and maintain myself.

Try TekJobs → · View the source⁠ (opens in a new tab) · Install from npm⁠ (opens in a new tab) · Talk to me about building systems like this