How I Used Claude Code to Build a Reusable Job Application System

I wanted a better way to apply to jobs. Not just a resume and a cover letter — a complete, polished application that shows who I am, what I’ve built, and why I’m interested in a specific role. Something that looks professional, loads fast, and can be tailored per company without starting from scratch every time.

So I built a system for it using Claude Code and my existing Astro website. Here’s how it works.

The problem with traditional applications

Most job applications are the same: upload a PDF resume, paste a cover letter into a text box, hit submit. Maybe you tweak a few bullet points per role. The experience is identical whether you’re deeply passionate about a company or just casting a wide net.

I wanted my applications to stand out — not with gimmicks, but with craft. A dedicated landing page that shows I’ve thought about why I want to work at this company. A tailored resume that emphasizes the right experience. Recommendations from real colleagues. Projects that are relevant to the role. All of it consistent, professional, and fast to produce.

The architecture

Everything lives in my personal website, built with Astro. The key insight was treating each job application as a page within my site rather than a separate document. This meant I could share components across applications while customizing the content.

Folder-per-application

Each application gets its own folder:

src/pages/
  resume.astro                          → generic resume
  company-role/
    index.astro                         → landing page
    resume.astro                        → tailored resume
  another-company-role/
    index.astro                         → landing page
    resume.astro                        → tailored resume
  _application-template.astro           → starter for new pages
  _resume-template.astro                → starter for new resumes

The URL structure is clean: /company-role for the landing page, /company-role/resume for the tailored resume. The underscore-prefixed templates don’t generate routes — they’re just files you copy.

Shared components

The real power is in the shared components. Rather than copy-pasting markup across pages, I extracted reusable pieces:

• HeroSection — Headshot, name, headline, subtitle, social links, optional video embed. The only thing that changes per application is the headline and subtitle.
• AboutSection — My standard bio. Hardcoded once, used everywhere. No props needed — just drop in <AboutSection />.
• ResumeLayout — The print-optimized resume layout with customizable props for summary, experience bullets, skills, projects, and even the website URL in the header. Each tailored resume just overrides what needs to change.
• RecommendationsSection — Pulls from a shared data file where each recommendation has an id. Pages can show all recommendations or filter to a subset.

Data-driven content

Recommendations, experience entries, education, and projects all live in a single shared-content.ts file. Each project has a featuredOn array that controls which pages it appears on. Adding a project to an application page is one line:

featuredOn: ['home', 'company-role', 'another-company-role'],

Recommendations work similarly — a getRecommendations() helper returns all of them, or you can filter by ID:

// All recommendations
getRecommendations()

// Just the ones relevant to this role
getRecommendations(['colleague-a', 'colleague-b', 'mentor-c'])

Creating a new application

With the system in place, spinning up a new application page takes minutes instead of hours:

1. Create a new folder (e.g., src/pages/company-role/)
2. Copy _application-template.astro as index.astro
3. Copy _resume-template.astro as resume.astro
4. Fill in the company-specific content (headline, “Why [Company]” section, summary)
5. Choose which projects and recommendations to feature
6. Tailor the resume bullets and skills for the role

Everything else — the layout, styling, social links, About Me section, experience history, education, print CSS — is inherited automatically. When I update my bio or add a new recommendation, it propagates across every application page.

The resume system

The resume deserves its own callout. /resume is a standalone, print-optimized page — no site chrome, no navigation. Hit Cmd+P and it saves as a clean PDF. The <title> tag controls the default filename.

Each tailored resume uses ResumeLayout with different props:

• Summary — Rewritten to emphasize what matters for the role
• Experience bullets — Same content, reordered to lead with the most relevant work
• Skills grid — Adjusted categories (e.g., adding “Automation” for a role that values workflow tooling)
• Projects — Only the ones relevant to the position
• Website URL — Points to the application page, not the homepage

The generic resume at /resume uses all the defaults. Tailored resumes override only what they need to.

What Claude Code did

I used Claude Code for the entire implementation. The workflow was collaborative: I decided what the system should look like, described the architecture I wanted, and Claude built it. Specifically:

• Component extraction — I identified that the hero, about section, and recommendations were duplicated. Claude extracted them into clean Astro components with the right props and slots.
• Data modeling — Claude set up the shared content file with TypeScript interfaces, the featuredOn filtering pattern, and the getRecommendations helper.
• Resume layout — I described wanting customizable resumes that fall back to sensible defaults. Claude built the ResumeLayout with props for every section that varies.
• Iterative refinement — We went back and forth on details: renaming “About” to “About Me,” reordering sections, adding the websiteUrl prop, updating grant language across all pages simultaneously.

The system evolved through conversation. I didn’t spec it all upfront — I made decisions as I saw what was possible, and Claude implemented them immediately.

Results

What used to take a full day — writing a cover letter, tweaking a resume, maybe building a one-off page — now takes under an hour. The output is significantly better: a professional landing page with tailored content, a print-ready resume, relevant project showcases, and real recommendations from colleagues.

More importantly, the system gets better over time. Every new recommendation, every new project, every refinement to my bio improves every application simultaneously.

Why build a system, not just apply?

I want to be clear about something: the point of this system isn’t to apply to as many jobs as possible. It’s the opposite. By automating the scaffolding — the layout, the formatting, the shared bio, the print CSS — I get to spend more time on the parts that actually matter: understanding what a company does, why the role exists, and writing a genuine case for why I’m the right person for it.

Every “Why [Company]” section is written from scratch. Every resume summary is rewritten for the role. The system doesn’t generate any of that — it just makes sure I’m not wasting time on boilerplate when I could be doing the real work of thinking about fit.

If I’m applying to a role at an AI company, I think building a system like this is part of the application. It shows how I think about problems: identify the repetitive parts, automate them, and redirect that effort toward the work that requires judgment.

The takeaway

That’s the real lesson here: AI-assisted development isn’t just about writing code faster. It’s about building systems that compound — where the work you do today makes tomorrow’s work easier, and where you’re freed up to focus on the things that can’t be templated.