Firstleaf

One storefront, on every screen

When I joined, the storefront wasn't built for phones, and the store and the subscription checkout looked and behaved like two different sites. Rebuilding them as one consistent, mobile-first experience was my first big project there.

Then we went after speed. Amplitude and Datadog showed where people actually went and where they waited; Lighthouse showed why. We worked through the flows that mattered most until every Lighthouse score was above 90.

A component library for developers and designers

I built the shared component library used by the whole frontend team — more than ten developers — and the three designers working with them. Three decisions kept it maintainable:

• Storybook as common ground. Designers could see how every component rendered, in every state, and iterate on it there instead of waiting for a page to be built.
• Base versus instance. Changing a base component is a library change, made on purpose, for everyone; a tweak that one page needs stays on that page. Keeping the two apart stopped one-off fixes from leaking across the site.
• Composition. Primary, secondary and tertiary buttons are all built on the same base button, so a fix lands once and reaches every variant.

Previews on demand

Together with DevOps I set up GitHub Actions to build, test and deploy to AWS. On top of that we built a small tool: comment /deploy on a pull request, and that branch gets built and deployed to its own preview on S3.

It grew from there. API branches got previews too, a frontend branch could be paired with a backend branch, and each preview could start from a clean database or a smaller dataset.

The wine directory

As engineering manager, I led the build of a wine directory meant to bring in organic search traffic. The starting point was a third-party reference database of 1.5 million wines. We used AI to clean it up and fill in attributes like region and varietal. Matching it against Firstleaf’s own catalog of about 10,000 wines was the easy part, since the brand already came in the data.

Every wine got its own page. The more interesting part was topic pages: from a template like “wines that pair well with {food}”, AI drafted the copy, a person reviewed it, and the page went live with a grid of relevant wines and an entry in the sitemap. Those grids are what made the directory work. They are internal links tying topic pages to wine pages, which helps people browse and helps search engines crawl.

All of it was server-side rendered from Rails templates, on demand and cached. A static build of 1.5 million pages would have taken forever; rendering on demand meant a page cost nothing until someone, or a crawler, asked for it.

Publishing was the delicate part. A site that suddenly grows by tens of thousands of pages can look like spam to Google, so we rolled out in steps: 10 pages, then 100, 500, 5,000 and 40,000. Between steps we waited a couple of weeks and checked Search Console before moving on, and tracked rankings with Ahrefs.

When I left there were about 50,000 topic pages, linking to roughly 400,000 of the 1.5 million wines. By its third month the directory was bringing in around ten conversions a month from organic search: early numbers, for a channel that takes time to mature and has no acquisition cost.

Leading the team

As lead engineer I led a team of five. For my last four years I was engineering manager of a cross-functional team of six — three frontend developers, a backend developer, QA and a designer — working alongside our product manager. I ran discovery with business and operations, turned requests into roadmaps, and reported outcomes to leadership and the board.

I also ran hiring for the team. I designed the take-home — find the bugs in a small wine-grid repo and improve it, close to the actual job — and did the technical and culture-fit interviews: about twenty candidates, four or five hires.