Rebecca Bakels: From waterbeds to a Wayfair competitor

Hi, I'm Rebecca Bakels. Welcome to City Furniture. This is my talk: Water Beds to Wayfair Competitor. Picture this, the seventies, Miami, water beds. This is the humble business origin of City Furniture, formerly known as Waterbed City, which 50 years later has now grown into the largest furniture retailer in Florida.

Our decades of growth and success is thanks to a company culture that never shies away from change. And in 1994, when the trend showed water beds weren't the future, the company segued into a complete home furniture store. we realized our e-commerce website was essentially the water bed of the web. It wouldn't be able to handle our ambitions to scale nationally and lead the competition with the latest web technologies. Thus, our dev team decided change was imperative.

Let's get into it. The most glaring issue at that time was we were slow, painfully slow. We were behind the curve on both speed and performance of our website, along with search engine optimization that could give us an advantage in Google result ranking. Knowing this, our dev team began implementing their own in-house server side rendering to prevent blank initial page views and provide the metadata necessary to appease the almighty Google bot.

While this is all impressive and ambitious, at the end of the day we're not an SSR focused company or a dev tools company. We're a furniture company, and even though we could fight through the pain of implementing this ourselves, it devoured the time we could be spending focusing on building features more closely related to our customers explicit request and needs. Not only was this taking our time in the process of writing it, but it was perpetually claiming domain over our future development via iterating over and maintaining this code base alone.

At first, we were afraid. We were petrified, kept thinking how other frameworks got you locked inside. We spent oh so many nights just thinking how we could go on, but we grew strong and we learned how to use Next.js with our website to solve both of our biggest pain points. Next.js was becoming more and more known as the production framework for React. What we liked about it over other options including our own, was the freedom to use what we wanted and were ready for and leave what we weren't.

It was opinionated just enough to give us serious power out of the box without overpowering our entire project. As we began our transition to Next.js, we were able to keep the parts of our stack that were working, utilize our preexisting microservices and integrate them seamlessly in our new architecture and still have a faster website that propelled us into the modern web experience on first deploy. We chilled with this for a year. It gave us what we needed and let us shift our focus back to our customers. Now that we're comfortable with Next.js,

we have grown our team and we've begun utilizing more features from the framework including the image component. Like SSR, we developed our own image component in house. Unlike our SSR, it was not a mess and we were able to use it for years. At the time, we weren't compelled to swap this out because the Next Image component didn't have a strong advantage over the one we built. In fact, for all intents and purposes they were essentially the same. Over time, this has changed.

Lighthouse scores between the two components pulled away from each other, favoring the Next.js component by four to 14 points during every comparison. The Next Image component also implements a few properties that were really helpful for us such as loader for dynamically assembling image url. In addition, it improved beyond us. It again becomes code we don't have to maintain ourselves as we transition away from our custom component. Now we had unlimited power and potential backing