Over the past six months, we’ve been working like crazy on something new. Something that no one has created before, and which solves a problem that has remained unsolved for years.
This week, our vision became a reality. We launched our beta with several leading internet companies. The beta version alone will make more than 10 million monthly users enjoy a faster, smoother, and more secure web experience. That’s a significant milestone for the company, and we thought it was time to give the new product a name, a logo, and a design that eloquently communicates what it’s all about.
The name had to be short, distinct, and memorable — and a “.com” domain. We narrowed our choices down to five, and asked our friends and colleagues for feedback. And there was one name that stood out: Zaraz. “It sounds like something magical,” one said. (It is magical — we just made our first customer’s website 65% faster with one line of code!) “Sounds like a superhero,” said another.
We love palindromes. The symmetry and “Z” characters make it look blazingly fast, and it even carries a hidden meaning. In Hebrew, our mother tongue, zaraz means “accelerator.” The choice was clear. Meet Zaraz.com, a third-party manager for the web, designed to speed up page loading time and collect more reliable information.
Today, all websites use third-party tools such as Google Analytics, Intercom, and Hotjar. The top 5,000 websites in the US implement, on average, 22 different third-party tools on every one of their pages. The top 10% of the most-visited pages on the web have more than 175 different tools. Moreover, 57% of the JavaScript execution time on the web today belongs to third parties.
Companies invest hours of development and tons of resources on optimizing websites with the hope of making them faster. But as long as they load this many third-party tools, it’ll be a losing battle. Zaraz solves this problem. With Zaraz, companies can load as many third-party tools as they need, without slowing down their website.
How we pivoted during Y Combinator
When we got into YC, we were working on a different product. We called it Sweeps because it helped companies maintain accurate analytics and “clean” their data. We built it because many of the companies we’ve worked with have had enormous difficulty collecting accurate and reliable data with their third-party tools. We thought it was a significant enough problem to solve, and built a product that could automatically detect flawed implementation practices and alert the dev team accordingly. With Sweeps, all you had to do was enter a URL, and we would crawl your website to catch all its implementation errors.
During the first YC group Office Hours, we were asked by our YC partners (Aaron Epstein, Tracy Young, Kevin Lin, and Michael Seibel) to set our Demo Day goals. At the time, we were selling Sweeps at $150 per month, had a few customers, and were making a few hundred dollars in monthly recurring revenue. When it was our turn to speak, we said, “$10k in MRR.” We thought that was ambitious, an almost impossible goal. Seibel responded, “Umm, maybe triple that?” We pushed our panic down and were like, “Oh yeah, sure, no problem.” We had no idea how we were going to pull it off.
The next two months were pure madness. We tried to schedule as many demos as possible. We exhausted our networks and asked other YC alumni to assist with intros to the companies they worked with in the past. We ultimately targeted large internet companies, as we realized there was no way to reach our Demo Day goals if we kept selling Sweeps for such a low price. So we decided to increase the price of Sweeps to $2,000 per month.
Our product wasn’t complete. It didn’t have all the features and functionalities we intended to build. It was a very lean MVP — and I would say the word minimum describes it better than viable. For it to generate value to our customers, it demanded a lot of behind-the-scenes manual work from our team. But product development wasn’t the focus. We wanted to feel confident that we were building a product people wanted, dare we say needed. We had about 150 sales demos during those two months. In every one of them, we would present all the errors we could find that would cause a company to collect inaccurate analytics. There was some demand, but not what we had expected. We weren’t able to sell it.
A month before Demo Day, we scheduled an Office Hours with Michael Seibel. The first question he asked was, “Why are people not buying?” We told him. The second question followed. “What else did you learn?” We answered instinctively: customers keep asking about page speed. During a demo, we would list all the third-party tools the customer was using. When customers saw this, their first reaction was some variation of, “Gee, are we really using so many?” Then they would ask, “Does this slow down the website?” and “How does it affect SEO?”
But more importantly, they asked if we could do something about it.
The first time this happened was even before YC, when we pitched Wix. It happened again in San Francisco with Opendoor. And again and again. “Well, so can you do something about it?” Michael asked. We didn’t know, but we agreed to spend eight hours researching the matter.
How we validated the pain points
We didn’t know if third-party tools were slowing down websites, so we decided to check. We listed all the companies we’d been in touch with. We loaded each website multiple times using our own laptops and mobile devices, and measured the results of various performance metrics using Google Lighthouse (a web performance measurement tool). We then blocked all the traffic for external third-party domains and loaded the customer’s site multiple times again. It might not have been the most accurate way of measuring, but our efforts generated significant enough results. Third parties were slowing down our customers’ websites. There was no doubt.
We decided it was worth our time and effort to automate the process we had just done manually, so we built our Third-Party Analyzer, a tool that would help us work at scale. We then tested the top 5,000 websites in the United States, and discovered that on average, third-party tools were responsible for a 40% slowdown.
We didn’t want to spend too much time building a solution to the problem of website slowdown before knowing whether it was worth something to someone, so we decided to do two things that would help us validate demand. Yo’av sat down to build a super-light MVP. Two weeks later, we launched it to the YC internal community, and had so many sign-ups that we couldn’t keep up with demand. It was clear that start-ups wanted it.
At the same time, Yair sent emails to every customer we met during YC. The email presented the new product we imagined building and the number of seconds we could potentially cut from their website loading times if we optimized third-party scripts. The responses were powerful.
We know how it feels when someone isn’t really interested in your offering. It felt absolutely different this time. We had CTOs and VPs from the world’s top internet companies responding within minutes of our sending the email — after we’d been chasing them for weeks! It was clear that enterprise customers wanted our product.
We decided to focus on the big enterprises. Companies with high traffic volume care about page speed more, as it affects their bottom line dramatically. As it turns out, Google did a lot of the “convincing” for us. We discovered they were pushing big ad spenders to take web performance more seriously, as slowness affects online conversion rates quite significantly. To this end, Google had been “punishing” slow websites with lower SEO rankings, a practice that has started to carry more weight since Google announced Core Web Vitals in May of this year. Core Web Vitals are a new set of speed and UX metrics that starting in 2021 will be used by Google’s algorithm to rank websites.
How we started building
We asked companies such as Twitch, Airbnb, Razorpay, BetterHelp, TrueCar, and 2U, as well as a few smaller players, to pick a few pages on their websites to see how we could optimize them. We called it “Proof of Concept.” We signed Letters of Intent, promising to ship a product that does what we claimed in just a few months. Working with those companies served the purpose of learning what we should build in light of which third-party tools they were using, how the tools were configured, and how exactly we would optimize their loading.
This week, we shipped the product we promised to build. It works far better than we anticipated, boosting website speeds by 60–65%! Our software loads in 5 ms and handles more than 200k requests per second. We have figured out a way to cleverly time the loading of different tools without losing any data. We’ve designed a beautiful and simple user interface. We’ve been working on dozens of different third-party integrations. And most importantly, those speed improvements will make the experience of millions of users faster, smoother, and more pleasant, increasing our customers’ conversion rates significantly.
We’re not fooling ourselves. We know we’ve got a long way to go. We have many things to learn and tons of things to build before we arrive at the product–market fit promised land. But one thing we know for sure: we are tackling a real problem, and we have a very innovative way of solving it.
And it works like magic.
The Zaraz Team
If you’d like to learn more about Zaraz, shoot us an email at contact@zaraz.com.
