Work and Experience

List migration, re-segmentation and deliverability for a member-based organization

A member-based organization was moving its email operation off Mailchimp onto Kajabi. The list had grown organically for years with no consistent schema: 10,299 raw contacts spread across overlapping exports, with duplicates under multiple spellings, syntactically invalid and undeliverable addresses, aged cohorts dating back years, and a block of contacts with no recoverable interest or consent signal at all.

• From 10,299 raw contacts to 4,862 validated, de-duplicated members, a reconciled migration, not a copy of the entropy.
• A 21-segment, four-axis taxonomy the team composes audiences from, instead of one undifferentiated list.
• Interest-capture forms and 5 tagging automations keep the taxonomy self-maintaining as new members arrive.

Recurring event automations and a suppression-safe contact pipeline

A business running a steady calendar of ticketed events needed its email automation to keep pace without manual rebuilding every cycle. Each event followed a similar shape, promote, sell entries, close with a results announcement, but with different dates, audiences and follow-up. Meanwhile the contact data flowing in from the store arrived unsegmented and duplicated, and the CRM already carried nine months of live history: automations mid-flight, contacts mid-sequence, engagement data that must not be corrupted.

• A repeatable event-automation pattern instantiated across three live event cycles instead of rebuilding from scratch.
• A ~10,000-contact CRM that stays de-duplicated and segmented automatically as sales come in.
• Recency-based holdouts keep buyers out of redundant promotion, complaint-rate protection by architecture, not luck.

A full membership lifecycle engine on a WordPress store

A WordPress and WooCommerce membership organization had completed a platform migration onto FluentCRM but had no system on top of it: no segmentation model, no automations, and no bridge between store events and CRM state. Members applied, were approved, paid, renewed and attended events, and every one of those transitions was being tracked by hand, in inboxes and spreadsheets, by people whose job was never meant to be lifecycle bookkeeping.

• A complete membership state machine, application, approval, purchase, renewal, running from one ruleset with no manual steps.
• Anniversary renewals automated on rolling 365-day wait states with pre-expiry reminders.
• Two yearly event campaigns with timed reminders, refund-triggered state rollback, per-event consent scoping and segment-targeted promotion.

Sending-platform escape for a restricted vertical, with the revenue flows rebuilt

An e-commerce brand in a restricted product vertical was forced off Klaviyo, the platform's acceptable-use enforcement, not anything the brand did wrong technically. That is a existential email problem: the welcome and cart-recovery flows that drive repeat revenue go dark on someone else's timeline, and the obvious replacements enforce similar policies, so picking the next platform casually risks a second shutdown in ninety days.

• A clean exit from Klaviyo onto a relay pre-cleared in writing for the vertical, no second ban cycle.
• Nine-email welcome and four-email cart-recovery flows live on purchase-aware triggers.
• The coupon popup captured 58 leads in its first weeks live.

An auditable ETL pipeline for moving contacts between CRMs and ESPs

CRM and ESP migrations fail quietly: records drop between export and import, custom fields land in the wrong destination or the wrong format, consent provenance gets lost in translation, and deliverability suffers because a dirty list moves wholesale onto a fresh sending reputation. The industry default, export a CSV, massage it in a spreadsheet, import and hope, has no audit trail, no repeatability and no answer when the client asks "where did those 300 contacts go?".

• Migrations that are auditable end to end, reconciled counts, not a black-box export-import.
• Custom fields and consent provenance preserved across platform schemas.
• Bad records quarantined with reason codes instead of silently imported or silently dropped.

Scores a sending domain the way inbox providers evaluate it

Before any migration or bulk send, the sending domain has to be sound or the mail will not land, and most domains that "look configured" are not. SPF records exceed the DNS lookup limit and silently permerror; DKIM signs but does not align; DMARC exists at p=none with no reporting address, observing nothing. None of this is visible by glancing at DNS records; it only shows up when you evaluate them the way a receiving provider does.

• A scored, severity-ranked view of a sending domain before any migration or bulk send.
• Catches the silent killers: SPF lookup-limit permerrors, unaligned DKIM, blind DMARC policies.
• Findings mapped to the enforced Gmail/Yahoo/Microsoft requirements, a remediation plan, not a report.

LMS progress driving CRM state through a member roadmap

Membership sites that tie learning progress to a CRM usually do it with brittle glue: hooks scattered across functions.php, unguarded direct writes, and no boundary between what the LMS believes and what the CRM believes. It works until it does not, a spoofed AJAX call marks a course complete, a plugin update reorders hooks, and suddenly member access, progress and CRM tags disagree with each other and nobody can say which one is true.

• LMS progress and CRM state synchronized through one explicit boundary contract.
• Capability-checked, nonce-verified handlers on every write path, no spoofable progress updates.
• Member access and roadmap driven from a single authoritative state, zero drift.

Lead routing, list hygiene and support triage as importable workflows

A lot of back-office work is repetitive and error-prone: validating and routing inbound leads, keeping lists clean before sends, triaging support requests against response-time expectations. The usual automation demos that circulate publicly are toys, happy-path chains with no validation, no error branches and hardcoded credentials, which is precisely why businesses distrust them in production.

• Four importable workflows covering lead routing, list hygiene, lead intelligence and support triage.
• Schema validation, deterministic routing and dedicated error branches, production-shaped, not demo-shaped.
• Runs on synthetic data with zero credentials, import, execute and inspect every node.

Liquid render path and asset pipeline taken to the practical ceiling

A Shopify store was slower than its content justified, a Lighthouse performance score around 75, with the storefront carrying heavy product imagery, banners and app scripts the business was not willing to give up. The brief was explicitly not "strip the store"; it was to reach the practical performance ceiling achievable with the existing merchandising in place, through engineering rather than subtraction.

• Lighthouse performance from ~75 to 95, the practical ceiling for the store's current merchandising.
• Strong desktop and solid mobile scores, verified as stable medians across repeated runs.
• Gains from render-path and asset engineering, the storefront kept every conversion asset.

Mobile Lighthouse 50 to 85 on a live WooCommerce site, regression-gated

A busy WordPress and WooCommerce site was paying for front-end weight it did not need: mobile Lighthouse performance sat at 50, with a 6.5 s Largest Contentful Paint, 790 ms of Total Blocking Time and a 5.3 s Speed Index on an emulated mid-range device. Main-thread long tasks and render-blocking resources dominated the critical rendering path, and every second of it was being paid by real visitors on real phones.

• Mobile Lighthouse performance from 50 to 85 on an emulated mid-range device.
• LCP cut from 6.5 s to 4.0 s, Total Blocking Time from 790 ms to 0 ms, Speed Index from 5.3 s to 2.3 s.
• CLS held near 0.01 throughout, zero layout or checkout regressions across the whole pass.

Scan findings verified live, then closed with defense in depth

WordPress sites needed defense in depth rather than a single security plugin left on defaults. On the anchor engagement, the starting point was an external scan scoring the production site 79/100 with a list of reported issues, and scan output is where the real work begins, not ends: findings had to be reproduced against production before anything changed, because hardening against false positives is wasted motion and hardening that breaks integrations is worse than the exposure.

• 7 live-confirmed findings, 7 corrected, including a critical XML-RPC exposure open to brute-force amplification and pingback DDoS reflection.
• Every fix dependency-checked against the stack first, hardening that never broke the automations the business runs on.
• Defense in depth across WAF, virtual patching, headers and attack surface, not a single plugin on defaults.

An English sales funnel inside a French WooCommerce store, no multilingual plugin

A French-language WooCommerce site needed to sell a book to an English-speaking audience through a dedicated funnel, landing, checkout and confirmation fully in English, without translating the rest of the store and without bolting a site-wide multilingual plugin onto a live production site for the sake of three pages. WPML-class machinery means duplicated content models, translation tables, locale switching and a permanent maintenance tax; for one product's purchase path, that is the wrong tool by an order of magnitude.

• An English purchase funnel live inside a French store, one product, three pages, zero multilingual plugin, zero site-locale changes.
• Fail-closed by construction: outside the allowlisted funnel, the French site cannot be affected.
• Translations survive WooCommerce checkout-fragment AJAX refreshes, the point where scoped i18n usually breaks.