Charles Ryan

This project provided a rare and thoroughly enjoyable opportunity. The client wanted to migrate their current site from WordPress to Shopify, and give it an overhaul in the process.

After the initial setup, the use of reusable Vue components and global SCSS mixins allowed me to increase the pace at which I completed portions of the site to a point where it almost felt like cheating. This build and several similar ones at our company helped contribute to the creation of a boilerplate component library meant to be used in future site builds to decrease the amount of time and effort required.

Update: as of early 2021 it looks like they've disabled all the actual ecommerce functionality, replacing add to cart buttons with links to another retailer's site.

The goal of this project was to replace the client's previous subscription checkout. This previous checkout flow was disjointed and prone to user abandonment as a result of visual differences between pages and a lack of intuitive next steps. Implementing a smooth and responsive single page application in its place greatly reduced the amount of friction and cognitive load involved in the checkout process.

As a developer working for an agency that primarily has clients platformed on Shopify, this was a unique opportunity. Both Shopify and Recharge (a popular Shopify app that handles subscriptions) provide out-of-the-box checkout experiences, and the extent of our work on them usually began and ended with styling tweaks. This client, however, has a business model that requires functionality beyond what most Shopify subscription apps provide. The service the client chose was entirely API-based, which gave me the chance to build a completely custom checkout interface.

I think site speed optimizations aren't nearly as glamorized as they should be. Maybe it's because, outside of analytics reports, there aren't many concrete results that project stakeholders can easily point to, but these projects have some of the largest ROI of any I've worked on. The end result of this particular optimization was an 18% improvement in average load time (21% on mobile), and a corresponding increase in positive commercial metrics for the client.

When this project was assigned to me, another developer had performed an analysis of the site from a performance perspective and provided several recommendations on improvements. By this time I had spent a few months working on various other features for this client. Their legacy codebase was extensive and bogged down by unnecessary complexity that had accumulated over the years. Needless to say, I had a few improvements already in mind that I was excited to implement.

This was a great project to work on. The client sells a lot of subscription products using the Recharge app on their Shopify store. They liked to manually send a free gift product with the second order in each customer's subscription, and asked our agency to automate the process.

I used AWS's API Gateway and Lambda to process data gathered from Recharge's webhooks to schedule the gift products with the appropriate shipments. This project serves as a perfect example of leveraging automation to save dozens of hours of manual work.

This was a generally straightforward collection page, with a couple challenges- product volume and customizable filters. A high volume of products is a typical reason for high load times on a lot of collection pages, and was solved for in this case by making several API requests for small groups of products. Upon initial page load, there are only enough products loaded to populate a couple rows beneath the user's viewport as the browser waits for the larger requests to return. Requests are also sent off upon various user interactions like filtering and sorting, to ensure that the most relevant products appear to the user even if they haven't been reached yet through standard pagination. Caching product data in browser storage also greatly improved load times for returning users.

The real challenge came from the client's request to customize the collection-based filters. I added the ability for the client to input the collections they wanted to be available to the user to filter products with in a way that required no code changes. Setting the code up to accept a long list of collections meant checking all the products in the current collection to make sure at least a few belonged to the collection-based filters before displaying those collections as potential filters to the user. It was difficult to balance this flexibility with rapid load times. The solution I ended up implementing was similar to the one I mentioned above. It involved making discrete API requests for filter-related collection data, utilizing data already made available by the requests that populated the product tiles, and caching the data in the user's browser for future visits.