The pain of a successful Hacker News launch
On June 2019, after months of hard work, we finally posted our MVP to Hacker News. It all looked good in the beginning, but then the things started to fall apart.
The launch post
Just one link on HN and it was a dream come true: thousands of people pouring in, tens of inbound links pointing to our site, big names of the industry giving praise, people joining the free trial, and investors reaching out to us.
We felt that our problem was validated and there is a need for this sort of a product. There were a lot of positives on the launch, so what could possibly go wrong?
To our big surprise, we had massive sites signing up for the trial in a matter of hours. One Brazilian site was so big that our servers could not handle the load. Our logs were screaming, and we soon ran out of file handles. Things started to fall apart.
Luckily we got over this panic situation relatively fast, but soon after we faced a more severe problem: our scheduled data aggregators were taking more and more time to finish.
We expected the time to increase slightly due to our design choices, but the biggest websites were taking hours to generate. It turned out the generation time started rising exponentially after a certain amount of data. We could see a system crash coming sooner or later. Of course we should have tested this, but hey, they teach us to avoid pre-mature optimization so
And this was not the only problem we had.
User interface problems
While many people genuinely loved the product and the user experience, we could not just ignore some of the invaluable feedback we got from the HN comments:
Terminology is new, data visualizations are new, app layout is unusual, the settings tab on the right is unusual
The UI is a bit confusing. The promised solutions to well-described problems are not yet there in the tool
That's it. In black and white: our product was not easy to use.
This problem was around our ego, really. We were under-estimating the importance for customer-driven development. It's easy to make mistakes by developing for just a few chosen friends and beta users.
But now we were suddenly facing constant usage from many different kinds of websites and users. For example, some of the users were generating more than 5000 different market segments in just a few days. It's impossible to take insights from such massive data views. Particularly when they take almost 10 seconds to load and render.
With these problems and all the million things you must do in a new startup, it started to be hard to maintain focus. The negatives were taking over our minds. Ultimately we could not figure out anything else than hitting the brakes and close our free trial. We also turned down a lucrative Segment invitation
Damn. Startups are hard.
Closing the trial gave us vital time to think things over.
To deal with the scalability issues, we started looking at different database options. We paid extra attention to TrailDB, which seemed like the perfect database for our use-case. Unfortunately, the project is abandoned on GitHub, and the lead developer had moved from Helsinki (where most of us are) to San Francisco.
After extensive research, we eventually came back to the same thing we were already using: an impressive Golang database Badger. We started utilizing it's streams and value identification bits to make a lightweight and highly performant solution for any data mass.
With the new system, we can collect terabytes of customer data and generate analytical reports in minutes, not hours. And we can collect and store everything from day one till the dawn of global eco-catastrophe.
User interface design is not much different from the server side. You really need to start from scratch multiple times to find the most straightforward and elegant solution to the problem at hand. And because we're solving a unique problem it's impossible to take inspiration from the existing analytics products like MixPanel or Amplitude.
So we started looking elsewhere. Products that handled big information masses and were genuinely embraced by the market. Products like Slack and Front. And many, many designs on Dribbble. In the end, our designers came up with a brilliant idea for the information architecture and how all the bits and pieces go perfectly in their right places.
We are now developing the product with 30+ websites from small to medium sized businesses with 1-2 million page views and with a high variety on their inbound marketing strategies.
Despite the early pains we are now comfortable about the future and cannot wait to bring the new version to market.