Most of my working life has been spent inside e-commerce data: prices that change hourly, listings that move between marketplaces, competitors who rebrand a product with a new title and photo and expect the matching logic to fail. It's a domain that punishes sloppy assumptions quickly, and that's taught me a few things I didn't expect going in.
Scale breaks assumptions before code does
A script that works cleanly for five sites is a different problem from one that has to work for fifty, and the difference is rarely about better code — it's about which assumptions were quietly baked in at five sites that stop holding at fifty. That lesson runs through most of my project work, and it's the reason SARA exists at all: to treat site-specific fragility as the default, not the exception.
The data is never the whole story
Marketplace data on its own — a price, a ranking, a listing — means very little without the context of what a business is trying to decide. Working on competitor intelligence and price intelligence made that unavoidable: the technical challenge (scrape it, match it, validate it) is only half the job. The other half is understanding what a pricing team, or a brand team, actually does with the number once it lands on their screen.
“The other half is understanding what a pricing team, or a brand team, actually does with the number once it lands on their screen.”
Reliability is a feature, not an afterthought
In this domain, a wrong number is worse than a missing one — a page that fails to load and gets misread as "price dropped to zero" is a more dangerous failure than a page that's simply absent from the report. That single lesson has shaped how I think about validation, retries and QA across every pipeline I've built since, more than any individual algorithm has.
A lot of this is also just a longer version of what's already covered under Analytics & Intelligence in my skills, and in more detail across the individual case studies in Selected Work.