Helping retail chains run education marathons for 40k people: Habithero case study

An exciting story from Leo Byakov, a founder of Zerocoder— one of the largest no-code communities out there. Find out how his side project managed to grow into a fascinating and complex tool large retailers use to train their staff.

Client

We help people get into low-code and no-code, curate educational courses and generally spread the word. On top of that, we have ongoing no-code projects done for companies in the Philippines. 

One of the projects I made (or side projects, you could say) is habithero.io. That was a simple website project that turned into something gigantic. It’s a Telegram chatbot that runs and manages educational marathons, primarily in large companies. 

When a marathon begins, people receive small tasks every day, and the management keeps track of who has completed tasks and who hasn't, with the option to kick out those who do not participate, incur penalties, and so on. 

Challenge

We help companies launch marathons for large audiences, lately for 20,000-40,000 people, who are all employees of a vast retail network. 

Before we automated everything, these marathons were managed manually. The idea was to help employees form the right habits, fulfill tasks, and report their progress publicly. Now, we just assist our clients in managing the content within the chatbot structure or creating custom marathons if something different is required. 

Naturally, extensive backend logic is involved. Previously we used Make but it became insufficient for our needs. It wasn’t able to handle a lot of data exchange and interactions. That’s why we switched to Directual—that was about 2-3 years ago. I spoke to Pavel, CEO of Directual, back then, and he mentioned that everything would work out—and indeed it did.

How did you discover Directual

As one of the founders of Zerocoder, I know just about any no-code/low-code platform out there. No-code is my bread and butter, has been before it was cool. From a development perspective, I'm not a programmer, but this project is intense in terms of load and many other aspects.

I've known Pavel for many years as well. Together with Pavel, I managed to transfer complex logic from Make to Directuall in just 3-4 weeks. There was a need to launch a marathon by a certain date and I managed it. I wrote the JS code (such as it was), and Nikita and Pavel both made sure it worked with my project. 

Technology

Backend: Directual

Admin tools: Retool

Analytics: coupler.io

What did you build with Directual?

A Telegram chatbot capable of executing complex logic scenarios and sustaining incredible stress during peak hours.

To list some functions, here’s what it does:

• Sends tasks every day
• Collects responses
• Calculates the results
• Reacts to each message
• Writes messages and reminders based on outstanding tasks
• Utilizes templates on the fly
• Analyzes data
• Provides reports
• and much more. 

At the end of each day, there's a report on who has submitted their tasks, who hasn't, and who has forgotten to do so. Different messages are sent to different chats when that happens. The bot also speaks in more than one language to accommodate all the team members. 

All the messages are taken from a pre-made library, and the real challenge lies in scaling it up. Now that the framework is more or less refined, configuring the settings can be done within the bot’s interface itself. 

Why was Directual chosen as a base technology?

Compared to competitors, Directual takes a few more steps to rig everything together. From this perspective, making calls to other systems is a bit more of a hassle, but what you gain after it's done is stability and speed. If personal data is less of a question, Directual is fantastic. However, if your business is regulated, it might get a bit more tricky. 

The API is convenient and easy to use, you can integrate anything, and scaling is a piece of cake. Even several hundreds of thousands of events all get processed fast—something other platforms can’t really do.

This is chiefly due to the simplicity of the architecture—scenarios and logic processing are very straightforward. That also implies certain limitations, yes, but to overcome that you simply need more logic cube operation. Once you adjust to that, it’s all worth it. On top of that, debugging and figuring out what isn’t working is really simple, even for someone like me.

What could be improved?

Perfection is unattainable…however.

A lot can be done.

Problems that cannot be solved with logic cubes, but can be with code, require documentation or some sort of AI assistant that will help overcome that. It’s quite a niche problem, but nonetheless.

The pricing could be clarified for sure. It’s hard to say how—there are a lot of moving parts and calculating a project estimate is challenging. This needs to be smoother and simpler, but I’m not sure where I would start, personally. 

Plans ahead

So far, this is a fun side project. We want to create a license for the bot and sell it so that our end users can focus on their marathons without our direct help. After all, we are involved in so many other projects as well.

Afterword

Want to learn more about this case study? Send us a message at hello@directual.com or head into one of our communities–links are below in the footer. Thank you for reading!