Adding Resume View Tracking to Talior.me

I just pushed an update to talior.me that solves a problem I kept running into while job hunting myself. When you are sending out a lot of tailored resumes, the process can start feeling one-directional. You apply, you wait, and you have almost no idea whether anyone actually opened the resume or clicked through to your portfolio. That lack of feedback gets frustrating fast.

So this update was about making resume views a little more observable.

The problem I wanted to solve

When I am applying seriously, I am not sending one generic resume everywhere. I am generating tailored versions for different companies and roles. That part was already working well.

What was missing was feedback.

I wanted a way to answer questions like:

• did this company actually open the resume?
• which version of my resume got viewed?
• can I trace interest back to a specific application without manually building custom links every time?

Before this change, the website field in the resume was just a static contact link. That is useful, but it does not tell me much about what is happening after I submit an application. The PR linked to issue #16, which was specifically about adding tracking to that website field.

That felt like a missing piece in the workflow.

If talior.me is supposed to help me run a high-volume application process, it should not just generate resumes. It should also give me some signal about what happens after they are sent.

What’s new in this update

Per-resume tracking support

PR #16 adds tracking-specific fields to the data model instead of treating this as a frontend-only hack. On the user side, there is now a global trackingEnabled flag and a trackingSlugPrefix. On the generated resume job side, there is now a trackingSlug, its own trackingEnabled flag, and an index on trackingSlug so those jobs can be looked up efficiently.

The main idea was to make tracking a first-class part of the resume-generation system.

New jobs inherit the user’s tracking preference

Another part I wanted was for tracking to feel automatic.

When a new job is created, the backend now reads the user’s global tracking preference and copies that into the new resume job. That means if I have tracking turned on at the account level, new tailored resumes automatically start with that behavior instead of forcing me to reconfigure it every time.

That matters because the whole point is reducing repetitive work, not adding more toggles to click through.

Tracking URL gets embedded without changing the visible resume text

This is the part I like most.

The PDF generation flow now keeps the visible website text clean, but lets the actual hyperlink point somewhere else through websiteHref when a tracking URL is available. The template still displays the normal website string, but the click target can be the tracking link instead.

So from the recruiter’s perspective, the resume still looks normal.

From my perspective, that website field becomes a traceable entry point tied to the application.

Cleaner tracking and filtering support

This PR also updates the tracker service and DTOs so jobs can be queried by trackingSlug, which makes the tracking system easier to inspect from the app side as more resumes get generated. The PR summary also notes that relevant DTOs and shared types were updated to carry the new tracking-related fields through the stack.

That is important because tracking is only useful if the data can actually be surfaced and filtered later.

Why this matters (for me)

This update came directly from my own job-search workflow.

When you are applying to a lot of roles, feedback loops matter. Even a small amount of signal helps. Knowing whether a resume was likely viewed is not the same thing as getting an interview, but it is still useful. It tells me whether the application might have been seen, which versions are getting attention, and whether the process is completely dead or at least moving somewhere.

That changes how I think about the product.

I do not want talior.me to only help me generate tailored resumes and then go silent. I want it to support more of the application workflow:

• generate the resume
• tailor it to the role
• send it out
• get at least some feedback on whether it was opened

That is the direction this PR pushes the product toward.

What I like technically about this change

I like this PR because it is a good example of a small product idea turning into a real full-stack feature.

It touches:

• schema design
• job creation defaults
• resume-processing logic
• PDF rendering
• tracking queries
• DTO and shared type updates
• UI behavior simplification

Those are my favorite kinds of changes because they force the product idea to stay coherent all the way through implementation.

It is to make resume-level tracking a real system primitive, wire it into generation, preserve a clean-looking resume, and keep the UX simple enough that it still feels invisible when I am applying quickly.

What I want to build next

The bigger goal is to make talior.me feel less like a one-off resume generator and more like a system for running the entire application process with better feedback loops.

And for me, resume view tracking was one of those missing pieces.