Vroom - Building an Blazing Fast Ecommerce Website From Scratch
I was hired as the first engineer in Vroom’s new NYC HQ to rewrite Vroom.com on a modern tech stack. I rebuilt the website from the ground up as a universal Javascript Single-Page Application using Node.js, React, and Redux. Later on I hired, managed, and mentored a team of 5 engineers to work on the codebase, and was promoted to “Engineering Lead”.
Company Overview
Vroom makes over $1b/yr in revenue buying and selling used cars online. Their goal is to make buying a used car as easy as buying a pair of shoes online. Vroom.com is the company’s flagship ecommerce website.
The Problem - Old Website
Unfortunately their website had a lot of issues, which is why I was hired to rewrite it. Here were some of the problems:
- Extremely slow. Pages would take anywhere from 500ms-5s to load. In the ecommerce world, this directly translates to lost revenue.
- Website had a lot of bugs
- Development time was very slow. Deployment was infrequent. The simplest of tasks would take weeks. The stakeholders were fed up.
- Expensive
Server costs were relatively high.
New Website
I decided to build a Universal Javascript Single-Page App (SPA) with Node.js, React, and Redux.
Why a SPA? Performance and more possibilities. Having spent the last year and a half working on a complex Node.js/React SPA at iHeart, I felt very comfortable with SPAs, and am convinced that they are the future of the web.
You can check out the React/Redux SPA boilerplate I created and used for the website. The boilerplate was spun off and used internally at my company for other apps as well.
I considered using Next.js, but ultimately decided to roll my own solution mainly because I prefer the control and flexibility of running my own framework. Having previously worked on a universal SPA with 20M unique visitors/month, I already knew how they work, and I didn’t see the advantage in confining myself to a framework with its under-the-hood “magic” and dealing with the inevitable edge cases that arise when you want to do something your framework can’t handle or run into some cryptic error. But not to knock on Next.js, it seems to be popular and gets a lot of praise. I would certainly revisit it next time around since it seems to have matured pretty well since then.
On the devops side, we used CircleCI for continuous integration, and hosted the site on Google Cloud using Docker and Kubernetes. Changes would first go to a staging branch before making it to production. Continuous Integration is a must as it makes life a hell of a lot easier.
From a management perspective, we ran on agile. All code changes were submitted as pull requests requiring code review before acceptance. We also progressively deployed each new rewritten page as soon as it was complete, instead of waiting for months to finish everything and releasing everything all at once.
We made heavy use of A/B testing with Optimizely, testing out new features and ensuring their viability before making them permanent.
Ultimately, the new website led to:
- Drastically improved page speeds and performance. This is largely due to being an SPA, and all the awesome things you can do with an SPA like caching vehicle data in memory.
- Drastically reduced server costs. Node.js is generally a lot cheaper than .NET due to requiring less CPU and memory.
- Significantly faster development time. Having a clean codebase and good processes in place means faster developmentpolitics.
Feedback
The team was happy with the new site, and I got promoted to “Engineering Lead”. It feels good when your CEO congratulates you for doing a great job on the site and tells you “wow, it’s so fast!”
Conclusion
I learned a ton from this whole experience - not only about tech, but also about management and company politics. I wrote about some of my tech learnings here, and I plan to write more about my learnings in the future.
I’m so grateful to have been given this opportunity. And of course I have to thank the team who brought this to life, and continue to carry it on after I’ve left.