DEV Community

Cover image for WorryBox
Andrew Hewitt
Andrew Hewitt

Posted on

WorryBox

I've always been a person who finds it easy to be happy. For as long as I can remember, I've had a natural optimism and a strong sense of grounding. But while I don't personally suffer from anxiety or depression, I've spent my life watching those I care about struggle with it—making mountains out of molehills, getting lost in worries over the most mundane things, or simply being unable to explain why they feel so down.

I've always wanted to help, but I've never had the words. How can I offer advice on an experience I've never had?

However, I did notice one critical pattern: a tendency to keep everything inside. When worries are kept internal, they multiply, building up into an overwhelming weight. It's not a matter of simply letting go; the thoughts are persistent and constantly loop like an irritating jingle. For people who suffer from this, simply "forgetting about it" isn't an option.

This led me to a simple idea: what if you could put them down? Not to forget them or make them disappear, but to transfer them from your head to a safe, external place. A place where they still exist, so they can be revisited if needed, but no longer occupy all the mental space. It was this simple thought, 20 years ago, that became the founding principle of Worrybox—an idea I later learned is a recognised therapeutic technique for clearing your mind. Even the same name is used. I am a little embarrassed I didn't know that at the time.

The idea for Worrybox sat, ironically, in my head for years. Nagging at me to do something about it. But with work commitments, and the feeling that such a platform, although helpful, was not something I could make enough money from to even support its own servers, meant I never got started.

This simple idea, however, came with a significant technological stumbling block. The core feature I envisioned was a simple counter to tell the worry-poster how many other people shared a similar concern. My goal was to deliver a powerful message of solidarity: "You are not alone."

Twenty years ago, matching one person's worry to another's—especially when they were worded differently—was incredibly difficult. We were limited to clunky keyword matching or time-consuming tokenisation. But today, with the new generation of LLM-based AI models, this kind of semantic matching is a breeze.

A push to get started

I have been a developer for a long time and have worked with many languages and technologies. I have made simple utilities, CRM systems, Games, and even hacked a drone to add sensors and make it fly through a sewage pipe. So, my instinct was a start from the ground up and keep a close eye on my own code. Even in recent years, as AI has become an excellent tool to enhance a developer's workflow, I would normally leave it for smaller tasks: Answering questions, brainstorming a new feature, reading multi-part logs (This is honestly the best use of AI I have found), and generally being there as a second brain. The idea of letting AI do all the work is not thrilling. I know from experience what a hassle it is to inherit a large codebase. Going through someone else's hard work with no idea what thought processes they went through while building. Letting AI do the entire codebase would leave me with something like that. But...

The "Kode with Kiro" hackathon, which I stumbled upon, seemed like an interesting way to get a non-profitable idea done. It gave me the push I needed to get started with WorryBox. With little time to spare on making things for myself, I considered trying a new approach. Although the hackathon suggests coding along with Kiro, I decided to take on the role of Project Manager and rely on the AI to let it handle complex tasks that I would have traditionally spent days on myself. I decided right from the start, I would supply the idea, prompts, any setup or external parts, but ultimately leave the code to the AI. At least for the duration of the competition. This felt a little dirty, but it meant I did not have to give up on my other commitments (My job, for one). I could simply get on with my work while Kiro got on with building the platform. I only needed to interact now and again to check on progress and steer the idea.

WorryBox - The Idea

Worrybox is a compassionate social platform designed to help users externalise their worries through structured posting, privacy controls, and supportive community interaction.

It allows you to put your worry into a safe, external place and see how many others have a similar one. This is made possible by the same AI technology that also helps moderate comments, ensuring the platform remains a safe and protected space for everyone.

In designing the user experience, every detail was considered. While most social networks feature a "Like" button, it felt entirely inappropriate for a platform dedicated to emotional vulnerability. You can't "like" a worry. Instead, I replaced it with a "Support" button, a small change that makes a huge impact on the feeling of solidarity and empathy.

Next to it, you'll find the "Me Too" button, which is powered by that semantic AI matching. It's a simple, yet powerful way for users to show they've had a similar experience. It’s a direct answer to the question "Am I the only one who feels this way?" and a clear signal that the community is here to show up for each other.

All this leads to the magic number that shows you are not alone.

The Journey

Kiro, as an app, makes it extremely easy to get started and comes with a logical workflow that begins with planning. Kiro takes the prompts and helps plan the full system, making changes where needed. Once the plan is confirmed by the user, Kiro goes ahead and plans out the steps needed to make it a reality. This same workflow is later followed in the same way for new features. Again the user needs to confirm the steps, but when happy, Kiro will begin work on the first step.

It was impressive to see Kiro work and comforting to see the level of detail in the preparation. The speed at which everything is slotted together can make a seasoned developer feel less like a coder and more like a manager (This is not a good thing). But thankfully, that doesn't last long.

While Kiro did turn out to be an excellent tool, and fully capable of doing most of the work, there were problems along the way that knowledge and experience of code were invaluable for solving.

The fix, remove, fix loop

Of course, a hands-off approach wasn't without its challenges. I had to test Kiro's work, and in doing so, I quickly found bugs. While Kiro's first version of Worrybox worked very well, as we progressed through the plan, I found pages would error due to syntax problems, some pages didn't exist at all, and some parts were not as initially designed.

This final point couldn't be helped. Kiro doesn't have emotions or any real understanding of the project's purpose. So, there were times when things had to be re-explained to get the correct result. To be fair, I didn't mind that part.

The biggest problem, however, was syntax errors. I found that each time Kiro got stuck in a loop was because of a simple HTML syntax issue. For example, while trying to find the cause of a page error, Kiro would determine there was a missing tag. To fix the problem, it would add the tag. But this would cause another problem, to which Kiro would determine the cause was an extra tag, and then simply remove it. This would bring us right back to the original problem. Since Kiro is capable of editing code and then running it to check for errors, my intervention was sometimes needed to end the madness. And so, although I had decided not to code at all for this project, I eventually had to do a little to keep the project going.

But it was only a little, I promise. 😅

In times of these loops, or when Kiro couldn't solve a problem, I found myself going in and manually making the required changes. This would have been faster if it were my own codebase, but because Kiro did most of the work, it took some time to find the problem. But all in all, it was no different from helping a co-worker with a problem. Sometimes the most skilled developers make mistakes so simple they can't see them, and a second set of eyes is invaluable.

The experience, overall, was almost exactly the same as leading a team of developers for a project. I have managed teams like this and had similar problems (not so much the fix loop).

Getting It Out There: The Cost of Doing Business

The next major hurdle I faced after building the platform was the money to run it. WorryBox is a hobby project, and as such, I have no backing or funding to pay for hosting, AI, or data storage. But Kiro was able to help with this, too. I told the AI my budget was zero and asked for a list of ideas.

Kiro’s suggestions came in tiers. The first ideas were outdated, pointing me toward open-source funding programs from major clouds like Google, Azure, and AWS that no longer existed. The second set of ideas suggested low-budget, pay-as-you-go hosting. While those weren't free, they were a step in the right direction.

But the third set of ideas was exactly what I needed: a truly free way to get everything running using generous free tiers from different providers:

Frontend: Vercel
Backend: Render
Database: Azure SQL
AI: Google AI Studio
Images: Cloudinary

This setup had me converting the existing PostgreSQL system to MS SQL, which introduced a few bugs. But worked out in the end. While running for a few days, though, I found that the startup time for Azure SQL was so slow that people would give up before they could log in to WorryBox.

When I mentioned this to Kiro, it suggested Neon. This meant converting back to PostgreSQL, but the change was worth it. Neon’s startup times for the free tier were excellent.

This kept things running well for about 10 days at a time. Then, Neon's free compute hours would run out and render Worrybox unusable. The same happened with Google AI Studio's generous monthly AI usage limit. For testing, it was great, but for general usage, not so much.

Fortunately, I recently received an anonymous donation specifically for the database. This, coupled with $100 of credits from Neon themselves, means that Worrybox doesn't stop working midway through the month. The AI won't count the number of similar worries after the monthly AI credit runs out, but that doesn't prevent users from interacting with the platform. As long as it keeps going for the duration of the competition is the main hurdle here, but I would ideally like WorryBox to keep working and helping people for as long as possible.

Final Thoughts

However it was built, this project is a personal one, driven by a desire to create a genuinely helpful tool for mental well-being. The "Kode with Kiro" hackathon provided the push I needed to move from concept to creation. But going forward, I will endeavour to keep it alive, and probably involve myself more with the codebase.

I invite you to explore Worrybox and share your thoughts. Your feedback is invaluable as I continue this journey.

Link to Worrybox (Alpha): worrybox.gigaelk.com
Link to Project on Kode with Kiro: https://devpost.com/software/worrybox
Support the Mission: Ko-Fi | Patreaon

Top comments (0)