Insurance Tech

What I did for the insurance-tech client

Via Studio Simpatico, I built a secure, user-specific email-preferences page tied into the platform's OKTA login flow and backed by Iterable. Due to the security profile, everything ran client-side, no PHP layer. The browser talked directly to Iterable, with the OKTA session establishing identity.

What the page does:

• Dynamically lists every email list the logged-in user is subscribed to, with per-list opt in / out.
• Fallback for users whose OKTA session carries multiple email addresses. They pick which address to manage.
• Submits push straight back to Iterable's API, confirmed with a small toast notification.

Followed up with Google Workspace SAML SSO end-to-end testing for a sibling product-updates site. Silent WordPress login at Subscriber level, full edge-case coverage on the auth flow.

How it helped the team

Identity and email preferences are the kind of work where bugs are silently expensive. A user opts out, the preference does not get saved, you keep sending emails, eventually they unsubscribe properly or report you. Building this with no server-side intermediate and Iterable as the source of truth meant fewer moving parts, less drift, and a clear audit trail in the browser console for support to read at 2am.

Why this way

Identity work is where most platforms quietly fall over. Too much glue, too many edge cases, no visibility when something silently breaks. The rule we followed: each user fact lives in exactly one system. If the browser can run the auth check safely, skip the PHP layer. Audit logs belong somewhere a support engineer can read at 2am. One user can have two valid work emails; build for it.

How I would describe working together

Via Studio Simpatico, in a setup where the agency owned the relationship and I owned the integration layer. Quick weekly syncs with the agency's tech lead. The work moved fast because the edge cases were specced before any code got written.