I’m a solo product developer and I’ve been working on Code Dog for over a year. Until now it supported four Git sources - GitLab (.com and Self-Hosted) and BitBucket (Cloud and Server). Today I decided to drop support for BitBucket Server and GitLab Self-Hosted.
Code Dog Server
After my initial success with Code Dog Cloud I thought it would be smart to respond to market demand and add support for BitBucket Server and GitLab Self-Hosted. So many people asked for that - the market is there, I thought, it would be foolish not to.
But with time came experience, and with experience came the understanding of just how painful supporting a product like that is. Not just for me, but for the user as well.
A pain for the user
To set it up, the user had to:
- Download it
- Create a Slack App
- Configure SSL so that Slack.com can connect to it
- Create a new BitBucket/GitLab user
- Configure access to BitBucket/GitLab
- And lastly, configure Code Dog
All that just to try and see if they like the app.
A pain for me
At first I distributed the app as an executable. It soon turned out a lot of people considered that “insecure”, and still more didn’t have a Linux server available. I switched my distribution to a Docker image, but even then I received email after email asking me how to run it on Windows or an environment I was not familiar with.
But that was just the beginning. To make it work I had to interface with Slack, BitBucket and GitLab.
Slack
Slack is not that bad - the documentation is good and support is great. However from time to time they will introduce new features or make changes that required me to spend a day or two coding. One such example were private channels.
Additionally, to create an app, the user needs to do a lot of pointing and clicking, maybe half an hour. Next he has to copy all the necessary keys and IDs to Code Dog to make it work. And then he needs to set up SSL so that Slack.com can connect to it.
This caused an endless stream of emails asking me “where do I find the App ID” or “how do I configure SSL”.
BitBucket
Don’t even get me started with BitBucket. The Self-Hosted version is based on a completely different code base than the Cloud version. It’s written in a different language, the APIs are different, and they have different bugs. I had to start from scratch.
And it’s so unimaginably slow. If an instance has more than a few hundered repos it would take minutes to communicate with it, resulting in HTTP timeouts.
I’m grateful to the users that helped me debug it and I’m really sorry to let you down by discontinuing the product.
GitLab
GitLab has even more bugs than BitBucket and is not app friendly at all, it’s like they weren’t aware apps were a thing when they designed it.
Luckily, the Self-Hosted version uses the same code as the Cloud version so I could reuse large chunks of my code.
Still, integrating with the app and configuring webhooks was so time consuming and frustrating that few users finished the setup.
My breaking point
A few days ago I got yet another email from a user asking me how to solve a mysterious missing_scope error with the Slack API.
I sat down and tried to debug it.
As I was slowly digging into the problem it began to dawn on me that catching up with API changes, library updates, and UI “improvements” is making my life miserable. Given the low return on investment I decided it’s not the best use of my time.
I gave up.
What will happen to the Cloud version?
I’m still working on the Cloud version. I can immediately catch errors, I have access to all of my debug information and I can deploy a new version within five minutes. I’m happy with it.
What will happen to the code?
I no longer wish to support it, but it’s good code. If you wish to buy it please contact me at hello@code-dog.app.
Conclusion
An indie maker should never attempt to tackle the standalone app market. The amount of energy required to support it is incomparably larger than supporting a SaaS product.
There is a reason why there are so many companies that specialise solely in supporting Atlassian products.