Nathan Joel

I own the client relationships across that portfolio end-to-end — from the first technical conversation through to high-volume batch releases. Each retailer has its own taxonomy, brand rules, locale mix, escalation paths. The job is to keep all of that legible to one team without turning every retailer into a special case.

What I’ve built up around it: client-specific config layers on a shared core, status views that surface the few things that need a human, a rhythm of small recurring touchpoints instead of heavyweight reviews.

I work directly with clients to capture their technical and output-format requirements — the column shapes they actually need, the locales they ship into, the validation rules a downstream system silently enforces. Most of that detail never makes it to a brief; you only get it by sitting in the call and asking the next question.

I then translate those requirements into delivery specs the engineering team can run with, and into product feedback when the same gap shows up in three clients in a row. That second loop — pattern-spotting across the portfolio and feeding it back upstream — is most of the job.

A recurring pattern across the portfolio: every client wanted a slightly different shape of CSV/XLSX out of the platform, and the way we handled that was accreting per-client special cases instead of paying off the abstraction. I wrote up a design proposal for productising the export layer — a schema-driven model with per-client mapping as configuration rather than code.

The proposal was adopted as the direction for that part of the product. The work that flowed from it now removes a class of bespoke engineering tickets we used to absorb on every onboarding.

The work the LLMs get credit for only happens because the data arrived in the right shape. I built the upstream of that: cross-language SKU translation that preserves brand and unit conventions; data standardisation and column consolidation that resolve dozens of source schemas into a single canonical one; batch content runs that survive partial failures and resume cleanly.

The hard parts are rarely the transformations — they’re idempotency, observability, and the long tail of edge cases that only appear at scale. I lean on small typed steps, explicit contracts between stages, and unforgiving tests.

A multi-step pipeline where retrieval, attribute extraction, copywriting and verification each get their own agent role, coordinated through a graph that knows which steps depend on which. The structure matters more than any single prompt — it’s what lets you tune one stage without destabilising the others.

I contributed full-stack features across it: the UI and APIs that operators use to drive runs and review output, prompt scaffolding around messy real-world product data, and verifier passes that catch the failure modes you only see at scale.

Retailers ask for the same shape of one-off task more often than anyone admits: pull these fields from these pages into a spreadsheet the merchandising team can open in Excel. I built one tool to do it well, then wrapped it in a thin per-client config so onboarding a new retailer takes hours, not a sprint.

The trick was treating it as a product, not a script — sensible defaults, polite rate-limiting, schema validation on the output, and a familiar enough interface that non-engineers can run it themselves.