What I learned building my first slack bot.


I built a slack bot which is now live on slacks app directory. While doing it, I had to face some challenges I wasn’t prepared for.

About our app: 
Olaph is a bot which helps you to take part at your stand-ups (or daily, weekly or however call it at your company ^^ a quick meeting where team members update each other about their current progress or challenges)
You can create a simple stand-up where you define the members, days, time and questions which should be asked to your team and Olaph will send those questions to your team-members and broadcast their answers to a specified channel.
We don’t use it as a replacement for our dailies, but as a reminder where you can think about what you actually did before the meeting starts (who doesn’t know the thinking-breaks when someone doesn’t remember what he did yesterday). 
Also, you can comment on the answers of others, without interrupting the daily.

Short side-note: 
The slack support is the best I worked with so far. They respond fast and precise, gave me tips and used feedback properly, e.g.: they changed the documentation on some places that I found confusing.

Slack suggests some third party SDK’s from developers which built wrappers for different languages, but none of#

them really suited our needs, so we started from scratch (we will publish our wrapper as well, but to make it open source, we have to change and extend some things)

The start was pretty straightforward, we created a slack app, registered our endpoints, and tested it in a dev-workspace.

When we were in our finishing-phase, things started to become interesting. 
To submit your app to the Slack app directory, you have to create a fresh workspace with your installed app & test-users to give Slack access to it. 
They have a submission checklist, where all necessary steps are described: https://api.slack.com/docs/slack-apps-checklist
So far so good, we clicked on submit, checked all points and submitted Olaph.
After some days, the Slack-team had some minor requests which we had to change (just naming of slash-commands and parameters for commands) 
And then we were allowed to publish our app!

Said and done, Olaph was live and some workspaces installed Olaph. 
The first week was horrible, errors here and there, gladly no crashes, but some users were not able to use Olaph properly.. 
Some of you might know this feeling, you built something, tried to test every part of your code and suddenly nothing works. 
And then I made the first mistake, I started to freak out.

“I tested the whole flow, I created a blank workspace, installed the app, used it, everything worked on my development system, how in the world is it possible that there are so many errors?”

I got a mail from a nice woman, which asked for help because she wasn’t able to create a stand-up. 
That calmed my mind a bit, there are actually users that ask for help instead of uninstalling everything and ignore my app forever.

The challenge was that Slack sends different data to your backend when its used in enterprise environments. 
There is some additional/different data, mixed userids and things I didn’t know before because I didn’t test our app on enterprise workspaces. Of course I didn’t, I don’t even know what that costs, because for enterprises you have to contact slack.

Well, for companies it might be expensive (or maybe not, as mentioned, I don’t know the prices) but I was a developer. I found out that you can request an enterprise test instance for developers. 
So I immediately requested an instance and.. waited. 
That’s why I had to fix errors which I saw in our logs, tell the users that this error is fixed, and wait for the next error.

It took about a week until I could set up my test-enterprise and test the app there. After I fixed every error and understood how enterprise workspaces work, I could publish a new release and our Users could finally use Olaph properly.

What I miss at slack are some statistics and numbers about my app, when you publish your app to the App directory, you don’t get any information about clicks, installs, uninstalls, how often slash commands are used or stuff like that. 
Of course, you are able to collect those data by yourself, but I have to invest time for that which could be used to improve or extend the product.

Slack has a public roadmap for developers to give insights into their current priorities, but the cards are not very detailed, so I don’t really know if we will get real statistics and numbers, but they are pretty active and I am pretty confident that slack will give us tools to improve our apps.

So far I really enjoyed the work with slack and their API, and I am looking forward to furthering changes and improvements.