The Salesforce developer portfolio that proves you can code — not just claim it

A Salesforce developer resume says "proficient in Apex and LWC." So does everyone else's. The thing that actually separates developer candidates in 2026 is rare and simple: a public GitHub repository a hiring manager can open and read. Most Salesforce dev applicants have none — no repo with Apex, no LWC, no tests — so having a good one is not table stakes, it's a differentiator very few bring. And for a developer, verifiable code outweighs a portfolio site: the engineering is the point. Here is what belongs in a repo that proves you can build, and how to put it on the resume.

Why a repo beats a claim

A line on a resume is an assertion; a repo is evidence. Hiring managers for Salesforce dev roles increasingly look for verifiable artifacts — GitHub repos, a package.xml, CI logs — and treat their absence, or an inability to talk about test coverage and deployment, as a red flag. A single well-built repo answers the question the interview is trying to reach: can this person actually ship clean, tested code? Pair it with the superbadges and projects angle, but know that real source code carries more weight than either.

What goes in a portfolio repo

One small, complete project proves more than ten half-built ones. Build a Salesforce DX project that shows the layers a real org has:

• Architecture, not a script. A bulkified trigger handler calling a service-layer class, not business logic crammed in the trigger — the structure signals you know how production code is organised.
• Tests that mean something. Salesforce's 75% coverage is a deployment minimum, not a quality bar. Show assertions, negative-path tests, bulk tests (200 records), and HTTP callout mocks — the things that prove the tests actually verify behaviour.
• LWC with Jest tests. A component plus its Jest tests shows front-end rigour, not just Apex.
• A CI/CD pipeline. A GitHub Actions workflow that runs the tests and does a sf project deploy — with visible logs — demonstrates the DevOps discipline teams actually hire for.
• A README that explains the design. The data model, the automation choices, why a trigger over a Flow — the reasoning, not just the code.

Label it honestly

A training or personal project is fine — but label it as such. Presenting a practice build as production customer work is the kind of thing that falls apart in an interview and ends the conversation, exactly the sort of resume mistake to avoid. "Personal project" with great code reads far better than an inflated claim you can't defend.

Put it on the resume as a verifiable line

Don't bury the repo — make it a scannable, specific line near your skills or projects, and quantify the engineering:

Before: "Proficient in Apex and LWC. Strong knowledge of Salesforce development and best practices."

An unverifiable claim — identical to every other developer resume.

After: "github.com/you/service-cloud-demo — Salesforce DX project: bulkified trigger-handler → service-layer Apex at 95% coverage (assertions, bulk and negative-path tests, callout mocks), an LWC with Jest tests, and a GitHub Actions test-and-deploy pipeline. Personal project."

Same skills — now a hiring manager can click and confirm them in thirty seconds.

Mirror the engineering vocabulary

Recruiters and the ATS search the real developer terms, so name them where they're true: Apex, LWC, Jest, SOQL, bulkification, governor limits, Salesforce DX, SFDX, GitHub Actions, Named Credentials, test coverage, trigger handler. A repo lets you use these words and back them up, which is the whole advantage.

Certifications

• Salesforce Certified Platform Developer I — the credential hiring managers filter developer applicants on; list it first.
• Platform Developer II (or a relevant architect cert) if you have it, framed via the certification roadmap. Certs prove you passed an exam; the repo proves you can apply it — carry both.

Keep the proof and the resume together

The friction is that your repo's best evidence — the coverage number, the patterns, the pipeline — lives in GitHub while your resume lives elsewhere, and they drift apart. In the SFCV builder your projects, certifications, and quantified outcomes sit in one place, so the repo link and its engineering highlights stay current and travel with every version you aim at a role on the jobs board.

Most Salesforce developer candidates ask a hiring manager to take "proficient in Apex" on faith. Be the one who links a clean, tested, honestly-labeled repo instead — architecture, real tests, a pipeline, a README that explains the choices. In a field where almost nobody brings verifiable code, the developer who does stops competing on claims and starts competing on proof.