Email Developer Portfolio Examples

A student emailed me last week, stuck on the part nobody warns you about.

"I've learned the HTML, I've coded a few emails. But I've never had a real email job. What do I even put in a portfolio so someone believes I can do this?"

That's the right question, and almost everyone asks it too late. You can learn the whole craft and still freeze at the moment you have to prove it to a stranger who's deciding whether to pay you.

So let me give you the honest answer I gave them. Your portfolio isn't a formality you bolt on at the end. For this job, it is the application. Let me show you what to build and how to present it so it does the convincing for you.

Why the portfolio beats the résumé here

Most jobs hire on a résumé and a conversation. Email development doesn't, and that's good news for you.

Think about what an employer actually needs to know before they trust you with a send that goes to 200,000 people. Not "did you graduate." Not "how many years." One question: do your emails actually render? Does your layout survive Outlook, Gmail, Apple Mail, and dark mode without falling apart?

A résumé can't answer that. A bullet that says "proficient in HTML email" is just a claim. Anyone can type it. So a hiring manager reading résumés for this role is basically guessing.

A portfolio removes the guess. When you show three coded emails plus the test screenshots proving they render clean across forty clients, you've answered the only question that matters before the interview even starts. That's the reframe worth keeping: a résumé tells them you can do the work; a portfolio shows them it's already done. For this role, the second one wins every time.

If you're still building the underlying skills, start with how to become an email developer and come back here when you have a couple of coded emails to show. This post is about turning that skill into proof.

What a strong email dev portfolio actually includes

A real portfolio isn't a gallery of pretty pictures. Pretty is easy to fake. What you're proving is that the thing works, so the pieces that carry weight are the ones a fraud couldn't produce.

Here's what belongs in it.

Three to five coded, cross-client-tested emails. Not thirty mediocre ones. A small set of polished, genuinely-tested builds beats a pile of half-finished experiments. Quality is the signal.

The test results that prove rendering. This is the part beginners skip and it's the most important part. For each email, show the previews across clients: Gmail, Outlook (a few versions), Apple Mail, dark mode, mobile. If you use Litmus or Email on Acid, screenshot the grid. This is your evidence. Without it, you're back to "trust me."

The actual code, linked. Put the HTML on GitHub so a technical reviewer can read it. Clean, commented, sensibly structured code tells a senior dev more in thirty seconds than your whole bio does. If your code is a mess of nested tables nobody can follow, that's information too.

A live preview, not just a screenshot. Host the rendered HTML somewhere clickable. Let them open the real email in their own browser and resize it. A static image can be Photoshopped. A live, responsive render can't.

At least one brand rebuild. Take a newsletter from a company everyone knows and rebuild it so well it's indistinguishable from the original, then show your version next to theirs. This proves you can hit a real-world bar, not just your own.

That's the whole kit. Notice none of it is "years of experience." It's all evidence.

Project ideas you can build this week

The fastest way out of "I have no real experience" is to stop waiting for permission and build the experience yourself. You don't need a client. You need a weekend and a few of these.

Each of these is a portfolio piece on its own. Pick three.

Rebuild a famous brand's newsletter. Pull up an email from Notion, Figma, Glossier, or any brand with a strong newsletter. Rebuild it from scratch in table-based HTML. Match it pixel for pixel, make it responsive, test it across clients. Show yours beside the original with a caption: "Rebuilt from scratch, tested across 40+ clients, renders identically in Outlook." This single piece tells an employer you can hit a professional standard.

Code a 3-email welcome series. Invent a brand (a coffee roaster, an app, whatever) and build a real welcome flow: the welcome, the "here's how to get started," the soft first offer. Now you're showing more than markup. You're showing you understand lifecycle email, which is what most of these jobs actually are. Caption it with the strategy so they see you think past the code.

Build a bulletproof button and a reusable template. A button that renders identically in Outlook (with the VML fallback) and everywhere else is a tiny piece that quietly screams "this person knows the cursed parts." Pair it with a clean, single-column starter template others could build on. It shows craft, not just output.

Build an interactive AMP email. Most email developers never touch AMP. A working interactive email (a carousel, an accordion, an in-email form) puts you in a small group and signals you're ahead of the curve. It's harder, it won't render everywhere, and that's exactly why it stands out.

Build a dark-mode-proof layout. Dark mode mangles colors, inverts logos, and breaks contrast in ways that catch most people off guard. An email you've deliberately engineered to survive dark mode, shown in both light and dark side by side, proves you handle the thing that trips up even working developers.

Build three of these and test them properly, and you have a portfolio stronger than most people who already hold the job.

How to present it so a hiring manager gets it in 5 seconds

Building the work is half the job. The other half is presenting it so a busy person understands it instantly, because they will not dig.

Where to host it. Keep it simple. A clean one-page site (even a free host) with your name, a short intro, and your pieces is plenty. Put the code on GitHub and link it. Host the live HTML previews so each email is clickable. You don't need a fancy custom build. You need it to load fast and read clearly. If anything, a developer who over-engineers their portfolio site instead of shipping it sends the wrong signal.

Caption every piece like they have five seconds, because they do. Each email needs a one-glance caption that answers three things: what it is, that it's tested, and what was hard about it. Like this:

3-email welcome series for a fictional coffee brand. Hand-coded, fully responsive, tested across Outlook 2016–365, Gmail, Apple Mail, and dark mode. Bulletproof buttons with VML fallback.

That caption does more work than a paragraph of bio. It tells a hiring manager you understand the real constraints before they've clicked a thing.

Lead with the proof. Put the test-result screenshots right next to each email, not buried. The rendering grid is the most persuasive thing you own. Make it the first thing they see.

Link the code, clearly. A visible "View the code" link on each piece invites the technical reviewer in. Hiding it makes them wonder what you're hiding.

When you're ready to apply, it helps to know where these roles actually live and what they pay, which I cover in remote email developer jobs.

Common mistakes that quietly sink a portfolio

I've seen good developers get passed over because of how they showed the work, not the work itself. Avoid these.

Screenshots with no proof of rendering. A nice picture of an email tells me nothing. Anyone can make one image look good. Without the cross-client test results, you've shown me art, not evidence. This is the single most common miss.

Too few pieces, or too many. One email looks like a fluke. Twenty unfinished ones look like you can't decide what's good. Three to five strong, tested pieces is the sweet spot.

No visible code. If a reviewer can't read your HTML, they can't verify you wrote clean, maintainable email code, which is half of what they're hiring for. Link the GitHub repo every time.

Untested emails dressed up as finished. If you didn't test it across clients, it isn't done, and a working email developer will know within one look in Outlook. Never present something you haven't actually run through the gauntlet. Getting comfortable with the tools that do this is worth real time; I rounded up the ones I'd start with in the best email developer tools.

FAQ

How many pieces should an email developer portfolio have? Three to five strong, fully-tested ones. Quality beats quantity badly here. One brand rebuild, one welcome series, and one piece that shows a hard technical skill (dark mode, AMP, or a bulletproof template) is already a solid portfolio. A pile of untested experiments hurts more than it helps.

Can I use fake or spec brands instead of real clients? Yes, and almost everyone starts this way. Rebuilding a famous brand's newsletter or inventing a brand for a welcome series is completely legitimate, as long as you're honest that it's a spec piece. Employers care that the email renders and the code is clean, not whether a real client paid for it. Just don't claim spec work was a real engagement.

Do I need a personal website for it? Not a fancy one. A simple, fast one-page site with your pieces, live previews, and links to the code is plenty. GitHub for the code plus hosted HTML previews covers the essentials. Don't let "I need to build the perfect portfolio site" become the excuse that stops you from shipping the actual emails, which are what matter.

What if I have no clients or job experience yet? That's exactly what spec work is for. You build the experience by building the pieces. A portfolio of self-initiated, cross-client-tested emails proves you can do the job whether or not anyone has paid you yet. In this field, demonstrated skill outranks a job title on your résumé, which is the whole reason the portfolio matters so much.

What's the one thing reviewers look at first? Whether your emails actually render. Put the cross-client test screenshots front and center, link the code, and make a live preview clickable. Everything else is secondary to proving the thing works where it has to work.

If you've coded even a couple of emails, you're closer than you think. The gap between you and a hired email developer usually isn't more skill. It's proof, presented clearly, that the skill already works. Build three solid pieces this week, test them honestly, caption them so a stranger gets it in five seconds, and you've built the one thing this whole field hires on.

That's the spirit behind our email developer career path: take the coding you have, point it at a role where proof beats pedigree, and let the work speak for you. You don't need someone to hand you experience first. You can build it. I've got you.