Senior full-stack developer — applied AI and web platforms

What the work actually is

I've been at IWConnect since March 2018. The role moved with the stack: it started in web and platform engineering on production sites and email infrastructure, and it now sits mostly in applied AI. Assistants, retrieval, recommendations, and the evaluation around them. Full-stack here means I own the whole thing: the API and data model underneath, and the interface people actually touch.

Applied AI, now

The assistants I build do one job inside a workflow that already exists, rather than answering anything about anything. An email helpdesk responder triages incoming support mail and drafts replies. An insurance policy renewal assistant prepares the renewal path for a person to approve. Both are prototypes, and deliberately kept there: each proves the workflow end to end with a human sign-off, and its project page says plainly what a production version would still need. In both cases the hard part wasn't generation. It was routing, grounding the answer in the right source, and deciding when the system should stay quiet instead of guessing.

How I work with AI inside the job

The same loop I use on my own systems applies to delivery at work: scope the change in writing, let the model draft inside that scope, review every line, gate it with tests and evaluation, and measure what changed. AI makes me faster; it doesn't change who owns the architecture, the review, or the decision to ship. The full loop is written up on the How I work with AI page.

Recommendations, and measuring them

I built a product recommendation engine, and then an SDK for measuring recommendation quality in a repeatable way. The second one is the one I'd defend: a recommender you can't measure is a recommender you can't improve, and "it looks reasonable" is not a metric.

Email and marketing infrastructure

A long stretch of email engineering: MJML templates, SMTP delivery, a Litmus-based sandbox workflow for validating rendering before send, and a preview tool for checking HTML email across clients. Unglamorous work with brutal compatibility constraints, and where I learned to treat rendering and QA as part of the build rather than a step after it.

WordPress platform engineering

Theme and plugin development, custom post types, and Elementor builds for production sites, plus a generator that turns a design-token system into WordPress-compatible HTML. Years of watching hardcoded post models age badly is exactly why Alex CMS has no hardcoded content models: every type is data, defined at runtime.

What I took from it

Working across all of those layers is why the systems I build now are whole systems rather than features. The retrieval layer, the content model, the cost tracing and the interface are all mine, and they're built to be handed over without me.