How Should an Email Developer in Spain Show MJML Systems and Private Client Campaigns?
An email developer should present each reusable template system or substantial campaign flow as a project, state their coding and testing responsibility, and link to an approved render, code sample, documentation, or anonymised case with no subscriber data.
Email work is often buried inside an ESP and judged through client-only analytics, yet the hard parts include component architecture, client rendering, accessibility, localisation, dark mode, and production handoff. A public portfolio should make those decisions visible without exposing recipients, content calendars, commercial results, or account access.
Which email projects should have their own entries?
Create entries for distinct systems or flows, such as a modular MJML library, transactional suite, onboarding sequence, localisation framework, dark-mode remediation, or campaign production system.
Explain audience, email type, reusable artifact, your role, and the testing or delivery boundary. Distinguish design, copy, coding, data integration, QA, and campaign operation when several people contributed.
Group individual sends when they use the same system and objective. Split a component library or transactional platform when it is maintained independently and has its own evidence.
- Public template: repository, documentation, or hosted preview.
- Client campaign: approved anonymised case or static render.
- Design system: component documentation and responsibility.
- Retired sequence: Archived with no ESP preview token.
What is the fast way to organise email work with IndieShow?
The fast way is to create one IndieShow card per email system or meaningful flow, use its current status, and select one reviewer-safe destination.
Use the description for channel problem, artifact, compatibility scope, and contribution; use the tag for MJML, transactional, lifecycle, accessibility, or another precise category. Add performance figures only when the client approves them and attribution is clear.
Order the page for the role or client you want and inspect the preview on desktop and mobile. IndieShow supplies the stable overview while previews, repositories, or approved cases host the detailed artifact.
Build your IndieShow pageClaim your handle, organise the projects in the editor, then review the $15 one-year and $30 lifetime publishing options in the dashboard.
How can private campaigns be shown without leaking subscriber data?
Show private campaigns with approved static renders, synthetic content, component documentation, or screenshots that have been recreated without real recipients, identifiers, tracking links, or account details.
Do not publish ESP dashboards, audience segments, email addresses, personalisation tokens populated with real data, internal offer calendars, revenue, or private preview URLs. Removing the visible name is not enough if links and metadata remain identifiable.
Label synthetic demonstrations honestly and state whether the work shown is code, design implementation, QA, or the entire production flow.
What evidence proves email-development quality?
Useful evidence shows the maintained code or component model, representative rendering, documented constraints, accessibility choices, and the testing process you actually owned.
Avoid universal compatibility claims unless the tested client matrix supports them. State the scope and date when rendering evidence can age as email clients change.
Keep one best destination per card and test it without an ESP session. The related guides cover private QA evidence and multi-format technical documentation.
Related IndieShow guides: presenting private test evidence · showing reusable technical systems
Why does IndieShow work for an email developer portfolio?
IndieShow works because it places template systems, campaign flows, experiments, and archived client work on one clear page without trying to host private subscriber or ESP data.
Editable cards let each system retain its role, destination, category, approved metric, and lifecycle. A buyer can scan breadth while specialist previews and repositories preserve the rendering and code detail.
Use IndieShow as the closing index of what you can prove and discuss, and keep client permission, source files, and analytics within their authorised systems.
Frequently asked questions
Which email projects should have their own entries?
Create entries for distinct systems or flows, such as a modular MJML library, transactional suite, onboarding sequence, localisation framework, dark-mode remediation, or campaign production system.
What is the fast way to organise email work with IndieShow?
The fast way is to create one IndieShow card per email system or meaningful flow, use its current status, and select one reviewer-safe destination.
How can private campaigns be shown without leaking subscriber data?
Show private campaigns with approved static renders, synthetic content, component documentation, or screenshots that have been recreated without real recipients, identifiers, tracking links, or account details.
What evidence proves email-development quality?
Useful evidence shows the maintained code or component model, representative rendering, documented constraints, accessibility choices, and the testing process you actually owned.
Why does IndieShow work for an email developer portfolio?
IndieShow works because it places template systems, campaign flows, experiments, and archived client work on one clear page without trying to host private subscriber or ESP data.