Speedrun Product 1 - Lockybot

I’ve launched my first product - LockyBot, for the speedrun today.

What is it? #

LockyBot is a Slack bot that lets teams manage shared resources and keep track of who is using what.

What is a resource? Well, anything that could be used only by a limited set of people at a time. It could be servers, license keys, conference rooms, company cars, and so on. You get the gist.

Example: #

Say, there are a couple of staging servers that are used by an engineering team of 5. At any point, only 2 can use it. And when a person is using it and has their features deployed, they don’t want others to start using it and overwriting their changes.

How is it handled currently is by posting to a channel asking if anyone’s using it, the person using actually has to see the message and respond, wait for everyone to say no, then log in. And also keep an eye out when someone else asks if they want to use it and so on.

But with LockyBot, you can quickly say you need a staging server for, say 3 hours. And when anyone wants to use the same server and try to reserve, LockyBot will prevent them from doing so and will let them know who is using it for how long.

Why build this? #

A couple of reasons mostly.

1. We’ve faced this exact problem, the one in my example above, at one of the past teams I was consulting with (fun fact: I got the idea to build RosterBird from the same job). We had a hotchpotch solution to deal with it but it had lots of issues on its own.
2. I’m intimately familiar with the Slack ecosystem and run an active Slack app that is doing relatively well. So, I had a bit of prior knowledge and that would make it easy for me to build this in 2 weeks timeframe. Also, building a product on top of a platform has an immense advantage for indiehacker (without much following), such as myself, in app discovery.

Specifically for these reasons is why I chose this idea to build.

Notes #

The two weeks were definitely tougher than I anticipated. Few mistakes I did, which I hope I could avoid in the subsequent projects.

First off, I spent the initial couple of days deciding on the idea and setting up the framework for the whole speedrun itself (deciding tools, approach for domain, emails, etc.), which ate into the time that was supposed to be spent on the product.

Even with the defined scope, it ballooned and I had to pause mid-sprint to revisit the features and more features that are not feasible to the icebox. For this, the constrained timing has definitely helped as otherwise I would’ve gone into the features rabbit hole and wouldn’t have shipped.

I unnecessarily wasted some time in choosing a payment provider. I always used Paddle for my projects, this time around I was thinking of using Stripe and it sent me into a rabbit hole. I’ll write up a separate post on this one.

Spending too much time on edge cases. I went too deep into handling all the possible edge case scenarios, many of which the users are unlikely to face. Even handling those edge cases, I treated them as normal path scenarios and paid too much attention to the response, actions, etc.

An example: when a user creates a resource, the bot sends a message that the resource is created, with a helpful button to "Lock" the resource.

An edge case is what if someone deletes it between the time the message is delivered and when the user clicks on it. Now, this *might* happen, but not the most common one. I could've just handled it with the generic flow of when resource not found.

Instead, I started handling it with the message "The resource you just created has already been deleted". This means I need to know where I'm receiving the lock information which adds further complexity. Furthermore, this is not a piece of extra information that the user would find useful, end of the day the resource has been deleted is just enough information. I finally scrapped that handling and went normally, but it is one example.

I couldn’t build the billing component. I wanted to release all products with pricing & billing upfront, but because it wasn’t a core feature I couldn’t build it out at the initial version. Hopefully, I can come back and add in the coming weeks.

I’ve been doing a bit of consulting work for ~10 hours a week which is taking away some time from this as well, once that is over, should make it relatively easy for subsequent projects.

Conclusion #

In a job, especially with a team or within a company, you always have to operate with certain constraints with certain workflows. The majority of time is not spent building stuff but on other organizational activities, meetings, etc…

And even within the building phase, most of it is spent articulating about it, writing stories about it, talking about it and crafting reviews for it and writing documentation, and so on.

So, this one was very enjoyable in comparison. To just put my head down and build, kindled the joy of just building stuff.

I’ve thought about abandoning the whole exercise a few times, but I think I’ll extend it for the next sprint for now and the sprint after, will decide then.