November 20, 2019

Botswick Conceptualized

Pieter Parker @Pawka

As our studio has grown, we've found that it's been difficult for us to keep track of the different day to day events that are happening across the entirety of our business. Those events are very important for any business to keep track of, and they were currently buried in a multitude of different services that we had to keep paying for each month.

While it's a completely valid strategy to leverage multiple services to run your business, we found ourselves yearning for a solution that let us pipe events that happened in our key services (Stripe, Google Cloud Platform) into our main communications service (Slack). We also wanted this solution to allow for us to easily interact with those services directly from Slack, and to be able to take action on events that were of importance to us from directly within our Slack without having to hop over to some other service.

Our thinking behind doing this was that if we were to design a solution like this well, we could not only use some of our internal programming knowledge to strongly streamline our internal business workflows and automate away more of the day to day tasks of our business, but we could also do away with some services entirely as they would become redundant.

One such example of this for us was being able to do away with the need for a service like Pingdom. Why pay for something to monitor your uptime when you can have Google Cloud Platform post a message right to your Slack when a site's health check failed? Why not even go further and do proactive integrity analysis on our clusters to see if we can get any early indicators of potential issues before they happen?

As we thought more about Botswick, the possibilities really seemed endless and would add immense value to our business as well as others. It was then that we knew we had to build Botswick.

Loading comments...