Relka: a job search with less manual tracking

Keep the application workflow familiar

I wanted people to keep applying the way they already did. In my experience, most recruiting communication arrived by email, making it a practical place to capture updates without asking someone to maintain another tool.

After connecting Gmail, Relka processes recruiting correspondence in the background, matches messages to applications, and builds timelines with status updates. Users can inspect and edit entries, or add an application by pasting a link or entering details.

Conversations with other students and people exploring similar ideas surfaced familiar tracking habits: spreadsheets, Notion, and attempts to automate the upkeep. They also raised adjacent possibilities, including deadline advice and agents that apply for jobs. I kept those out of scope to test the tracking itself first.

Find the limits of a simple parser

I began with text-matching rules rather than a model API. I wanted to see how far a simpler approach could go while keeping costs and latency low.

Personal use and early testing exposed its limits. In one case, several emails about the same application became separate application records. Recognizing recruiting language was only part of the problem; connecting incomplete messages into a coherent history was harder.

I used a capable LLM to organize a sample of my own emails, reviewed its groupings, and used that reference to guide parser experiments with Codex. It gave me a concrete target to compare against, without establishing accuracy across other users’ emails.

The engine now combines rules with selective model classification and structured extraction. Clear cases can stay deterministic; others get semantic interpretation before reconciliation with application records. I’ve deployed and tested this version and seen better results in my own use. That’s a qualitative observation, rather than an accuracy or cost benchmark.

Make the supporting evidence readable

The first interface exposed too much email content at once. I iterated toward showing key details first, with the underlying message available when someone wants to inspect it. Users can also correct application and timeline details.

That matters because tracking errors undermine the reason to use Relka. I’m more concerned about missing an important recruiting update than surfacing an extra item, but uncertain messages still need careful matching. The goal is a history someone can understand and rely on; reliability is still part of what I’m testing.

Put a narrow product in front of users

I recruited a small private beta through the UCLA Anderson community. In roughly the first week, about four or five people I didn’t know signed up, and three or four connected Gmail. So far, I believe one tester is using it actively; I’m still following up with the others. These are approximate early counts, not retention measures.

Recruitment also exposed entry barriers: some people were reluctant to grant email access, while others used Outlook-based school email for recruiting. One detailed tester conversation raised parsing inaccuracies and interest in surfacing actions and deadlines. I’m collecting more feedback before expanding the product.

For me, Relka has replaced the spreadsheet: application timelines and statuses update from my emails. I don’t yet know whether it will replace other users’ trackers.

My biggest win so far is getting a focused capability in front of people early. Before opening a public beta, I want private testers to be happy with the tracker and most to have stopped using their previous method. Continued use and fewer reported corrections would give me more evidence to build on. I’m still testing that.