Building ResumeeNow: The Engineering Behind an AI-Powered Resume Platform

How I built an AI-powered resume app with resume parsing, ATS audits, cover letter generation, and reliable PDF export.

A few forms, a live preview, a couple of templates, a PDF export button, and that would be it.

That assumption did not last long.

As soon as I added resume import, AI tailoring, ATS audits, cover letter generation, and export that actually had to look right on paper, the project stopped being a simple CRUD-style frontend. It became a set of connected systems that all had to agree with each other.

That was the real challenge.

The hard part was not just building screens. The hard part was making import, editing, AI workflows, export, notifications, and account-aware behavior feel like one coherent app.

What I Was Actually Building

At first, I described ResumeeNow as a resume builder.

A more accurate description now is this: it is an AI-powered resume platform where users can import an existing resume, edit it in a structured builder, tailor it for a role with AI, run an ATS audit, generate a cover letter, and export a polished PDF.

That shift matters, because it changed the engineering constraints.

A simple form app can get away with loose state and one-directional flows. This project could not. The moment imported data, AI-generated content, and exported documents all had to match, I needed stronger architecture and clearer boundaries.

The Stack I Chose
I built ResumeeNow with:

• React 19
• Vite 7
• TypeScript
• Tailwind CSS 4
• React Router 7
• React Query 5
• Zustand 5
• Supabase Auth + Postgres
• Vercel API routes
• Supabase Edge Functions
• pdfjs-dist, unpdf, and mammoth
• Playwright Core for browser-based PDF rendering
• Zod for validation

That stack let me move quickly, but only because I kept the responsibilities separated.

On the frontend, routes, builders, dashboards, and templates live in their own feature layers. On the backend, privileged behavior lives in API routes, and AI calls go through a dedicated gateway instead of being scattered across the client.

High-Level Architecture

The easiest way to understand the project is to look at it as four user-facing surfaces backed by two server runtimes.

This architecture evolved naturally from the project requirements.

The landing page and docs are public. The dashboard and builder are authenticated. Admin routes are privileged. AI goes through a separate edge function. Export goes through a server-rendered print path. Notifications go through a dedicated delivery route.

Once I accepted that the project had multiple surfaces with different risks, the codebase became much easier to reason about.

1. Splitting the App Into Clear Surfaces

One of the smallest but most important decisions I made was separating the app by route boundaries.

Instead of letting everything live inside one giant application shell, I split public, protected, print, and admin flows at the router level.

Source Spotlight: Router Boundaries

<Route path="/print/resume" element={<ResumePrintPage />} />
<Route path="/" element={<LandingPage />} />
<Route element={<ProtectedAppLayout />}>
  <Route path="/dashboard" element={<Dashboard />} />
  <Route path="/builder/:id" element={<BuilderPage />} />
  <Route element={<AdminRouteLayout />}>
    <Route path="/admin" element={<Admin />} />
    <Route path="/admin/users" element={<AdminUsers />} />
  </Route>
</Route>

This looks simple, but it carries a lot of architectural meaning.

The print surface is isolated. The public landing page stays outside the protected app. Admin routes sit behind their own gate. That kept responsibilities clear and prevented the project from turning into one overgrown frontend where every page inherited assumptions it should not have had.

That separation also helped later when I added more backend behavior. Once the route boundaries were clear, it was easier to decide what belonged in the client and what needed to move behind server-side contracts.

2. Resume Import Turned It Into a Real System

The feature that changed the nature of the project most was import.

It is easy to build a resume editor when users start from empty fields. It is much harder when they upload a PDF and expect the app to turn it into clean, editable data.

That forced me to build a parsing pipeline.

Import Pipeline

The import route does not just accept a file and hope for the best. It authenticates the request, validates the upload, extracts text on the server, checks whether the text is usable, and only then hands it off to the parser that produces structured resume data.

Source Spotlight: Import Route

const joined = modules.cleanupSectionText(pageTexts.join('\n\n'));
if (!modules.isReadableDocumentText(joined)) {
  throw new Error(
    'Could not extract reliable text from this PDF. This often happens with scanned or image-based PDFs without OCR.',
  );
}

That was one of the best product decisions in the whole project.

Bad parsing is worse than a clear failure message. If the app cannot build trustworthy editor state from a file, it should say so.

3. The Builder Had to Become a Stable Data Model

Once import existed, the builder could no longer be a loose collection of inputs.

I needed one normalized resume shape that could support:

• manual editing
• imported data
• AI-generated rewrites
• multiple templates
• live preview
• PDF export
• persistence and reload

That changed how I thought about the project.

What users experience as “a resume editor” is actually a coordination layer between domain data, UI editing, template rendering, and export. If those layers drift apart, the app becomes fragile very fast.

So the builder evolved into a set of dedicated modules: domain types for resume data, builder hooks for controller logic, preview components for document rendering, and export helpers that validate payloads before they ever reach the print surface.

That was one of the clearest moments where the project stopped feeling like a page and started feeling like an application.

4. AI Could Not Just Be a Button

One of the core facts about ResumeeNow is that it is AI-powered.

But I did not want AI to be a marketing label or a thin prompt wrapper. I wanted it to behave like real infrastructure inside the project.

The app currently supports three main AI workflows:

• AI Tailor
• ATS Audit
• Cover Letter generation

What made those workflows hard was not only generating text. It was controlling them properly.

I needed session validation, plan-aware access, rate limiting, concurrency handling, usage tracking, and a clear boundary between client requests and model execution. That is why AI goes through a dedicated edge function rather than being called directly from random components.

Source Spotlight: AI as a Policy Boundary

const { data: aiGate, error: aiGateError } = await supabaseClient
  .rpc("begin_ai_request", { user_id_param: user.id })
  .single();

beginRequest = aiGate as BeginAiRequestResult | null;

if (aiGateError || !beginRequest) {
  throw new HttpError(500, "Failed to begin AI request.", {
    error: "AI_GATE_FAILED",
    details: aiGateError?.message || "Unknown error",
  });
}

This was an important shift in how I treated AI.

The model call itself is not the whole feature. The surrounding system is the feature. Who can use it? How often? Under what plan? What happens if two requests collide? How do credits and limits behave? How does the result plug back into the builder without feeling detached?

That is why the AI layer in this project feels more like a workflow engine than a single API call.

5. PDF Export Became Its Own Engineering Problem

In a resume app, export quality is not optional.

The PDF is the thing users actually send to recruiters, hiring managers, and application portals. So it had to be reliable.

I quickly learned that “export to PDF” is not just a button. It is its own rendering problem.

I needed:

• consistent page sizing
• reliable font loading
• print-specific rendering
• predictable pagination
• a server-side render path
• parity between what the user sees and what gets downloaded

That is why export goes through a dedicated print surface and a browser-based render path rather than trying to serialize arbitrary client HTML directly.

Export Flow

flowchart LR
  A[Builder state] --> B[Validated export payload]
  B --> C[/api/export-pdf]
  C --> D[/print/resume]
  D --> E[Wait for print readiness and fonts]
  E --> F[Chromium render]
  F --> G[Final PDF]

The trickiest part here was page breaks. A resume looks cheap very fast if the layout splits in the wrong place.

Source Spotlight: Pagination Logic

while (unit.bottom > pageBoundary + BREAK_TOLERANCE_PX) {
  const nextBreak =
    unit.top > currentPageStart + BREAK_TOLERANCE_PX
      ? unit.top
      : pageBoundary;

  currentPageStart = nextBreak;
  breaks.push(nextBreak);

This is one of those tiny pieces of code that carries a much bigger idea.

I was not relying on the browser to “figure it out.” I added explicit page-break calculation based on measured layout units so lines and blocks would break more predictably across A4 pages.

That made export feel much more trustworthy.

6. The Invisible Operational Work Mattered a Lot

Some of the least visible parts of the project ended up being some of the most important:

• authentication
• account status checks
• notification preferences
• notification delivery state
• admin access control
• audit logging
• plan-aware AI usage

These are not flashy features, but they are the difference between a demo and a real app.

A good example is notification delivery. I did not want notification sending to be a loose fire-and-forget action. I wanted it to behave like a tracked event with preference checks, deduplication, and delivery status.

Source Spotlight: Notification Deduplication

let existingEvent: NotificationEventRecord | null = null;
if (isOneTimeType) {
  existingEvent = await getExistingOneTimeEvent(
    supabase,
    user.id,
    requestBody.type,
  );
  if (existingEvent && existingEvent.status !== 'failed') {
    res.status(200).send('Notification already handled.');
    return;
  }
}

This kind of logic is boring in the best way.

A welcome email should not send twice because a request retried. A waitlist event should not duplicate itself. AI usage alerts should not spam the user multiple times in the same day. Once I started thinking in terms of event state instead of just “send email now,” the system got much more robust.

The same thinking showed up in the admin layer too. Riskier actions were pushed through server-side helpers with explicit role checks and audit logging instead of being casually mixed into normal client behavior.

7. Testing the Quiet Failures

I did not approach testing as a blanket “write tests for everything” exercise.

Instead, I focused on the parts of the project that could quietly break trust:

• export payload normalization
• pagination behavior
• inline formatting
• AI request control
• persistent cache behavior
• runtime validation
• ATS audit logic

These are not always the most visible things in the UI, but they are the places where regressions hurt most. If export starts producing subtle layout errors or AI request behavior becomes inconsistent, users do not always know why. They just stop trusting the app.

That is why a lot of my testing effort went into the seams between features rather than the flashy surface layer.

8. What I Would Do Differently

If I were building ResumeeNow again from scratch, I would do a few things earlier.

I would document the architecture sooner. The project grew from “resume builder” into a multi-surface system faster than I expected, and clearer internal docs would have saved time.

I would also split some server modules earlier. The notification route, for example, now owns parsing, authentication, preferences, deduplication, persistence, email construction, and delivery behavior. It works, but it is already a clear signal for future refactoring.

And I would formalize some contracts earlier, especially around the AI and export paths, because those are the places where frontend and backend assumptions get tightly coupled.

Final Thoughts
Building ResumeeNow taught me something I keep coming back to:

the complexity of a project usually hides in the workflows between features, not in the feature list itself.

The hard part was not making a resume builder UI.

The hard part was making all of these work together cleanly:

• imported document text
• normalized builder state
• AI-assisted workflows
• ATS audit behavior
• cover letter generation
• PDF rendering
• notification delivery
• account-aware permissions

That is what made the project interesting.

ResumeeNow started as a simple idea. What I ended up building was an AI-powered system of parsers, renderers, workflows, and boundaries that all work together to make the app feel simple.

And that, more than anything else, is what this project taught me: simple products are often powered by a lot of invisible engineering.

Check Out the Project

If you want to explore the code, architecture, and implementation details more closely, the ResumeeNow repository is available here:

GitHub Repo

I’m still improving the project, especially around architecture, AI workflows, and export reliability, but this build taught me a lot about what it really takes to turn a simple app idea into a more complete system.