OnClock is Launching in Alpha

We have finally launched the first alpha version of OnClock. After two years of beta development, we are proud to announce our change to the Alpha version.

We spent countless hours ensuring that OnClock could be stable and usable for everyone. When we first created OnClock, we didn't think this would become a project this big but here we are. In this announcement post, we will discuss the significant changes that make OnClock what it is today.

We plan to be as open as possible on our development processes, tooling and the upcoming changes to OnClock.

We started working on OnClock in July 2021 when we noticed a problem happening. The team behind OnClock loves to play Grand Theft Auto roleplay servers. The server we were playing on had all their emergency services (and companies) on different Discord servers. It was very hard to know how many people were on duty in the different services. The most obvious problem was when the police officers wanted to know if there were any prison guards on duty, there was no way to do so easily. We started developing OnClock right away as a way to bridge the gap between those Discord servers and share this information (how many employees are active for a given service).

The first-ever version of OnClock was ready 15 days later. Every Discord server participating had their data hard-coded inside the code base. The OnClock Discord bot could only know who was on duty by showing a list of Discord users with a specific Discord role (i.e On-Duty).

We quickly realized that this wouldn't work forever and we started working on a database integration using SQLite since we only planned to use OnClock for this community. With the database came the ability to add other businesses dynamically. We made this possible through commands sent to the bot inside the Discord server of that company. In the same update, around mid-September, we introduced the fact that OnClock could store the on-duty state of the employees on its own.

We then spent some months fixing the little bugs that slipped under our keystrokes, making sure that we had a relatively good code base and that everything was very stable. We quickly grew to support 5 different businesses that were part of this community and using our product daily.

As we noticed that most of the businesses using OnClock were emergency services, we decided it was time to create a web interface. We built over the following months a dashboard that would allow our users to connect to a community they were part of (because they are in their Discord server), the service they are playing as and see who was on duty. We then created the different pages you know today to manage the vehicle fleet, assignation and finally assign each vehicle to a call card (a task). We built this web interface learning from the mistakes we made building our last computer-assisted dispatch (CAD).

Having a web application required us to create a REST API so that we could communicate to our database and have the Discord bot perform actions when something in the interface changed and vice-versa. We built our web app using Vue.js, our API using Fastify.js and our real-time ability using socket.io. At this stage of development, we wanted to make those updates as quickly as possible. Considering the task ahead, it was understandable but ultimately we made some poor choices that we learned from later on. The biggest was probably to build the API directly tied to the existing bot. At that time, it was a lot quicker to develop and we could worry about ensuring we had a fast and working web application early. Needless to say, we succeeded.

Today, OnClock has changed a lot. We are launching the Alpha version as we just released our biggest update. We previously said that we built our API directly tied to our Discord bot, but it is no longer the case. This change was needed but was huge, and we were worried about performance issues.

When we rebuilt the API, we learned from this mistake and since we were completely changing it, why not update the database to something that can handle much bigger loads and is quicker than SQLite? So we also changed our database to use MySQL in the same update. Not only were we changing our API, bot and SQL infrastructure, but in order to make this work all together we needed to change something else. Our deployment method.

From its birth, we had been using a process manager called pm2 to manage our API instance. We knew that this would need to change in the future when we first decided to use it and now was the time. Discord had also launched two new versions of its API and was pushing forward with its slash commands. We knew at this point that if we wanted to commercialize OnClock, we would need to implement slash commands. Again, as we were completely decoupling the API and the bot, why not reconstruct it from scratch too? It took us 5 months to make all those changes.

The deployment of our new infrastructure was a huge success. We have not had any major downtime since then and we grew a lot. A lot more than we expected. As we closed our previous product and redirected users to OnClock, we quickly gained momentum and gained over a hundred registered communities. We had our Discord bot verified soon after and are now working on making ends meet with a small monthly subscription that gives access to additional features.

What about the future of OnClock? Well, we are hard at work fixing the little bugs that might have crept in during the rapid development phases. We are also actively developing a mobile app so that it's easier to manage the status of your employees from your mobile devices. Finally, we are finalizing our landing page and preparing to accept secured payments from credit cards and Paypal!

Here are some of the things we are working on:

If you feel like you have an idea for a feature that would benefit your community and many others, please create a Feature Request, we will review it and possibly add it to our roadmap.

This is all for now, thank you for reading this post and we hope to see you on duty very soon!