May 2019 Summaries

The Checkly team recently optimized a Postgres query crucial to their dashboard, reducing response times from an average of ~100ms with peaks to a steady 1ms to 10ms. The optimization involved analyzing performance issues, testing fixes, and applying simple Postgres optimizations. A key finding was that two queries were consuming most of the execution time, one of which could be improved by using a composite index on `checkId` and `startedAt` fields in descending order. This solution resulted in a significant reduction in response times and p95 metric value, with Heroku metrics showing a drop from ~3 seconds to 175ms. The optimization was made possible by leveraging tools such as Heroku's pg:outliers command and Postgres' graphical interface for slowest execution time tab. The experience highlights the importance of finding the right angle, testing data, and confirming hypotheses in performance fixes.

There is a lot of dogma around shipping a product in startup land, with some founders following strict patterns they got from books or influencers' tweets, such as "Ship Early", which can be the right approach when entering new markets but not suitable for established ones. The author of Checkly, a new product in a competitive market, took a more measured approach, focusing on ease of use, UX, pricing and focus, rather than competing on feature set. This requires a bedrock of solid backend infrastructure, which is often developed using Agile or waterfall methods. First impressions matter, as users are forgiving but will be put off by broken code, and the term Minimal Viable Product (MVP) should be defined based on the specific market and requirements. In some cases, an MVP can be a simple, functional product that meets 95% of its users' needs, rather than striving for perfection.

During the spring and summer of 2018, I negotiated a possible acquihire of Checkly/moi with Datadog. The process began when a representative from Datadog emailed me to inquire about Checkly and potential integration benefits for both customers. We discussed the possibility of integrating dev accounts, testing, and marketplace features. This initial contact was likely a reconnaissance mission, as I later received a follow-up message indicating a closer partnership between Checkly and Datadog. The meetings progressed with multiple Zoom calls, in-person discussions, and coffee breaks, where we discussed various topics, including the Datadog product, my background, and the company's direction. I met the two founders of another startup that Datadog had acquired, who shared their experience integrating their product into the larger company. The CTO also spoke with me about technical challenges and growth. An NDA was signed before my trip to Paris, ensuring open communication about technical details. Despite discussions with multiple people at various levels of the organization, no concrete offers were made, but I kept working on Checkly as if nothing was happening. Ultimately, Datadog decided that I would have to move to Paris for an agreement, which was a deal-breaker for me due to personal and professional reasons. The experience was valuable, and I learned a lot about the process and the company, even though it didn't work out.

I experimented with different customer feedback tools for my early-stage company Checkly, including Hotjar's Incoming feature, Drift chat widget, SurveyMonkey survey, and a public GitHub project roadmap with voting. I found that Hotjar's Incoming was surprisingly effective at collecting feedback from users, but struggled with its other features. The Drift chat widget turned out to be incredibly useful for customer support and sales, while the SurveyMonkey survey had a low response rate. Adding a public roadmap with voting helped me align with customer needs and engage my growing community of paying customers.