Emails that behave like small apps — and degrade like good HTML.

At Kenscio I build AMP for Email campaigns for e-commerce and pharmacy brands: product carousels, in-inbox forms, and content that updates after send. The interesting engineering isn't the interactivity — it's making sure nobody without AMP support ever notices anything missing.

Project: Client campaigns
Role: Email developer
Timeline: 2024 — present
Stack: AMP4EMAIL · HTML · CSS

The brief

Campaign emails have a conversion problem baked into the medium: every action requires leaving the inbox, loading a page, and re-establishing context. AMP for Email removes that hop — recipients can browse variants, pick options and submit answers inside the message. The mandate for clients was direct: use that capability where it earns engagement, without ever risking a broken render for the majority of the list.

The constraints

AMP4EMAIL is a strict subset, not "HTML with extras". No external state (amp-state must be inline JSON), no [src] or [href] bindings, one <style amp-custom> under 50KB with no !important, transitions limited to opacity and transform. The validator is the gatekeeper — if it doesn't pass, Gmail won't render it.
Sender registration and CORS. Dynamic emails only render for allow-listed senders, and every action-xhr endpoint has to answer with AMP-specific CORS headers.
The audience isn't only Gmail. A meaningful share of any Indian consumer list opens in Outlook, Apple Mail and everything else — none of which run AMP.
Pharmacy clients add compliance review. Content and claims are reviewed, so templates need to be editable by non-developers without touching the interactive machinery.

The build

Every campaign ships as a three-part MIME message: the AMP part (text/x-amp-html) for supporting clients, a fully-featured HTML part with the same content statically laid out, and a plain-text part. The discipline is writing the HTML fallback first — it defines the complete story, and the AMP layer adds behaviour on top rather than carrying content the fallback lacks.

On the interactive layer, the components that pull their weight in real campaigns:

amp-carousel for product and variant browsing;
amp-bind for selection state: size pickers, quantity steppers, computed totals;
amp-form + amp-mustache for in-inbox surveys and preference capture, with designed submit-error states — an error the recipient understands is part of the deliverable;
amp-timeago so time-based copy stays accurate whenever the email is opened.

One habit that pays for itself: a pre-flight validation script in the build pipeline. AMP's rules are unforgiving about things ordinary HTML tolerates — a stray attribute, an http:// image, a fractional-second transition (which Gmail silently drops) — and catching them before the ESP does turns a review cycle into a save.

The outcome

Clients get campaigns where the inbox itself is the landing page — browsing and responding happen at the moment of attention, not after a redirect. Just as importantly, the fallback discipline means the non-AMP majority of the list receives a first-class static email, not a degraded one.

The working patterns from this practice are public in my Email Lab — four AMP templates you can paste into Google's Playground and validate yourself.

← previous casePhotography Portfolio next case →Transactional Email System