What I’ve Built So Far With Tailor.me

I have been building Tailor.me for one pretty simple reason: applying to jobs at volume is exhausting.

At the start, the problem I wanted to solve was resume fatigue. Every application felt like the same loop over and over again: copy the job description, figure out what mattered, pick the right experiences, rewrite bullets, tweak the formatting, export the PDF, and move on to the next one. It was repetitive work, and even worse, it was the kind of repetitive work that still demanded a lot of attention every single time.

So Tailor.me started as my attempt to automate that part of the process.

But over time, the project has become much more than that.

The more I used it for my own job search, the more obvious it became that resume generation was only one piece of the workflow. The real problem was not just “how do I tailor a resume faster?” It was “how do I run the whole application process with less friction, less repeated effort, and better feedback?”

That shift is what the development so far has really been about.

The problem I wanted to solve

A tailored resume is useful, but job hunting is never just about producing a PDF.

Once you start applying seriously, the workflow expands fast:

• tailoring content for each role
• keeping track of which jobs are in progress
• deciding which format makes sense for which application
• staying organized across companies and positions
• figuring out whether anyone even looked at what you sent

That is where a lot of the friction shows up.

I did not want Tailor.me to be a one-off AI demo where you paste in a job description, get a resume back, and then have to manage everything else in separate tools. I wanted it to become something closer to a personal system for running the job search itself.

What’s changed so far

It started with automating the actual tailoring

The first version of Tailor.me was focused on the core resume-generation loop.

The app takes a job description, extracts requirements and skills, selects relevant experiences and projects from a structured profile, rewrites bullets using AI, and generates a PDF that is ready to submit. Under the hood, I built it as a TypeScript monorepo with a Next.js frontend, a NestJS API, a separate NestJS worker, PostgreSQL with Prisma, BullMQ with Redis for job processing, and real-time updates over Socket.IO. That gave me a system that could process resume jobs in the background instead of blocking the UI and could handle multiple jobs concurrently.

That part solved the most obvious pain point: the actual time it takes to tailor a resume.

Instead of spending 30 to 45 minutes manually adapting each application, I now had a workflow that could do the heavy lifting in the background while still keeping me in control of the final result.

Then it became a workflow tool, not just a generator

Once the resume generation itself was working well, the next bottleneck became obvious: the application process around it was still messy.

So I added a built-in job tracker to Tailor.me. The idea was to stop treating each resume like an isolated output and start treating each application like an object moving through a workflow. Jobs could be organized around company and position, filtered by status, and moved through a clearer pipeline. I also added an “Apply & Next” flow, which is probably one of my favorite small product decisions so far because it matches exactly how I actually apply: finish one, mark it done, and immediately move to the next ready application.

That changed the shape of the project.

At that point, Tailor.me stopped feeling like “an AI resume builder” and started feeling more like a job-application system.

Then I made the presentation reusable with appearance presets

The next issue I kept running into was that tailored content was only half the story. The format changed, too.

A new grad application does not always want the same presentation as a more experienced role. Sometimes I wanted projects and education to lead. Sometimes I wanted experience to dominate. Sometimes I wanted a cleaner font and more breathing room. Other times, I wanted a denser format that could fit more relevant material.

Before this update, it was still too manual.

So I added appearance presets as a real system inside the app, with support for named presets, font family, font size, section ordering, default preset selection, a dedicated Appearance page, and a preset selector directly inside the resume builder. More importantly, I wired presets into the actual generation pipeline so appearance was not just a temporary UI state. It became part of how a tailored resume gets produced.

That was a meaningful step for me because it moved Tailor.me closer to supporting different job-search contexts instead of assuming one resume shape fits everything.

Then I added resume view tracking for feedback loops

One of the most frustrating parts of applying is how little signal you get back.

You tailor the resume, submit it, and then everything disappears into a black box. You usually do not know whether it was opened, which version got attention, or whether a particular application is completely dead, versus simply quiet.

So I added resume view tracking.

This made tracking a first-class part of the data model instead of something hacked in at the UI layer. There is now a user-level tracking preference, tracking data at the generated job level, and a tracking slug that can be queried efficiently. I also changed the PDF generation flow so the visible website text on the resume can stay clean while the actual hyperlink points to a trackable URL when tracking is enabled.

That feature matters because it closes a loop that was missing before.

Tailor.me is no longer just helping produce resumes. It is starting to tell me something about what happens after I send them out.

The bigger change is not any one feature

Looking back, I think the most interesting part of the development so far is not any single PR. It is the direction.

Each update pushed Tailor.me a little further away from being a narrow resume generator and a little closer to being a complete operating layer for job applications:

• generate tailored material
• manage application state
• reuse presentation styles
• capture lightweight feedback after submission

That progression feels natural because each feature came from the same source: repeated friction in my own workflow.

Why this matters (for me)

I like building products that come directly out of real usage, and Tailor.me is probably the clearest example of that for me right now.

This project did not come from trying to invent a flashy AI use case. It came from doing something annoying over and over again and wanting a better system for it.

That is why I care about the details here.

I care that job processes run in the background and show live progress. I care that the tracker reduces context switching. I care that presets remove repeated formatting work. I care that tracking creates at least some visibility after an application is sent. None of those are especially glamorous features on their own, but together they make the product feel much more useful in day-to-day use.

That is the standard I want for Tailor.me: not just interesting, but actually useful when I am in the middle of a real job search.

What I like technically about this project so far

What I like most is that every product decision has forced the architecture to become more coherent.

Even though the project started with AI-assisted resume generation, the interesting engineering work has been in turning that into a real system:

• a monorepo with shared types across apps
• background job processing with concurrency and retries
• WebSocket-based live progress updates
• structured profile data that AI can actually reason over
• generation pipelines that handle both content and appearance
• tracking support that lives in the schema, API, and PDF rendering flow

Those are my favorite kinds of projects because they are not just about adding features. They are about making the internals line up with the product idea.

And in Tailor.me, the product idea has become much clearer over time.

What I want to build next

There is still a lot I want to do here.

The obvious next step is to keep extending Tailor.me from a resume tool into a full application workflow system. That probably means things like smarter prioritization, better analytics on application progress, richer notes around each role, reminders and follow-ups, and more feedback loops that help answer whether the process is actually working.

I also think there is room to make the system more opinionated in useful ways. Right now, it helps me do the work faster. Over time, I want it to help me make better decisions about what to apply to, how to present myself for that role, and what signals are worth paying attention to afterward.

That is the direction I am most excited about.

So far, Tailor.me has gone from “automate the annoying parts of tailoring a resume” to “build a system that supports the whole job-application workflow.”

And honestly, I think that is the real product.