Why I keep a recruiter resume separate from my full portfolio.

One identity, two different reading speeds

A recruiter may have only a few minutes to decide whether my skills, experience, and selected projects match an open role. A hiring manager, collaborator, or client may want more: project status, screenshots, technical decisions, writing samples, and links to working software. Trying to satisfy both readers on one page can make the fast path too dense and the detailed path too shallow.

I solve that problem by maintaining a concise developer resume site and a broader professional portfolio. They share verified facts and link to each other, but they do not copy entire pages back and forth.

The recruiter site answers the first questions quickly

The resume site starts with my professional headline, Bergen County, New Jersey location, technical skills, experience, Fullstack Academy education, and selected projects. It gives recruiters direct access to my resume, GitHub, LinkedIn, and full portfolio without requiring them to work through long project narratives first.

The project list is intentionally selective. It highlights current work such as Il Veliero, Cutz By Casper, Greater Expectation, Jukebox Pro, and Book Buddy. The goal is not to place every article, photograph, or experiment on a recruiting page. The goal is to make the strongest relevant evidence easy to scan.

The portfolio carries the deeper proof

The full portfolio has a different job. Its projects page can connect selected work to detailed case studies, public applications, repositories, screenshots, and honest status labels. The writing archive gives me room to explain planning, testing, documentation, accessibility, field operations, and the decisions behind a project.

That depth matters because a project card can only say so much. A case study can explain what the project is for, what I worked on, what evidence is public, what remains in development, and what I learned. The portfolio is where those details belong.

I avoid duplication by changing the level of detail

When the same project appears on both sites, the facts should agree: project name, status, technology, live link, and repository link. The writing should not be identical. The resume site provides the concise recruiting summary; the portfolio provides the fuller explanation and evidence.

This distinction also protects clarity. A short resume summary does not need several paragraphs of background, and a case study should not be reduced to a list of technologies. Each page can do its own job while pointing readers to the next appropriate level of detail.

The shared facts must remain consistent

Separate purposes do not justify conflicting information. I check that both sites use the same professional name, current positioning, location, education, project status, and destination links. I also keep the relationship explicit: the resume links to the portfolio, projects, GitHub, and LinkedIn, while the portfolio links back to the recruiter-focused resume.

That consistency helps readers recognize the same professional record whether they search for Frank Smith III in New Jersey or use the shorter Frank Smith New Jersey name variant. The useful signal is not repetition. It is matching facts, working links, and clear ownership.

My maintenance checklist for both sites

A two-site structure only works if both properties stay current. My review focuses on a small set of practical checks:

• Confirm that featured project links and repositories still work.
• Keep project statuses accurate and avoid implying unverified results.
• Use concise summaries on the resume and fuller evidence on the portfolio.
• Preserve reciprocal links so readers can move between both views.
• Check canonical URLs, sitemaps, mobile layout, images, and contact paths.
• Update both sites when a verified project or professional fact materially changes.

I do not need to change both sites every time I publish an article. I update the recruiter site when the new information changes the concise professional record. I update the portfolio when a project needs deeper proof or a new lesson is worth documenting.

What this structure gives the reader

The recruiter gets a focused page with the information needed for a first review. The deeper reader gets a portfolio with project proof, context, and original writing. I get one professional identity with two deliberate paths instead of two competing copies of the same website.

The result is simpler to maintain because each property has a clear boundary. When I decide where new information belongs, I can ask one question: is this a concise recruiting fact, or is it evidence that deserves more context? The answer usually makes the destination clear.