DEV Community: Andrew Hewitt

The Echo Chamber of Content

Andrew Hewitt — Tue, 09 Dec 2025 22:11:55 +0000

Creating a successful blog post, especially one that details a new project like DinkySub, feels great. Even better is having other platforms recognise it. But, as a new founder, I am, of course, obsessively interested in how my platform is performing, and as such, I spend far too much time searching for it myself. One search, simply typing the word "DinkySub" into Google to see if the word is spreading, showed me a different problem: AI content theft by other bloggers.

Their Goal: Speeding Up Creation with AI

In my original blog post, I wrote about how I had created DinkySub as an attempt to escape the office and spend more time with my family.

When I recently checked Google for "DinkySub" to see how the post was ranking, I expected to see my original dev.to article and maybe some project pages. I did. But I also found copies and rewrites appearing on other sites. For a normal blog post, it may be hard to notice. But when the AI forgets to change the project names, they become easy to find.

The Direct Plagiarist: Fatih Soysal
A post attributed to Fatih Soysal. This content was my original article, translated into Turkish, and completely rewritten using AI, likely to bypass detection. The author presented it as if they were the creator of DinkySub with zero attribution or links back to the original article. This looks like a case of automated plagiarism with the author (if he even exists as a real person) not even proofreading the results.

The Corporate Huckster: Q2BSTUDIO
The most egregious case was from Q2BSTUDIO, a software development company. They took a Spanish translation of my original post and placed it on their company blog. The article uses my first-person narrative ("I launched DinkySub...") but then uses the entire story as a case study to advertise their own services:

"En Q2BSTUDIO entendemos esta filosofía aplicada a clientes y productos. Como empresa de desarrollo de software ofrecemos servicios..." They are essentially claiming my personal journey and intellectual property—including the success story of DinkySub—to sell their own business services, all without a single word of attribution.

A frustrating reality
The combination of content scrapers and powerful Large Language Models makes automated plagiarism easier, faster, and more effective at hiding than ever before. In my case, I could easily find the unique word associated with my product, but in most cases, where blog posts are for a discussion of a technology, the posts can be copied and reused without anyone noticing.

Your Story
The Dev.To platform is a great place for content. And therefore a great place for scraping. Have you found any of your articles to be plagiarised? Did it look like an AI automated job to you?

From Corporate Burnout to Side Hustle: I Shipped DinkySub in 2 Months with an AI Co-Pilot (and its Terrible Business Ideas)

Andrew Hewitt — Sun, 02 Nov 2025 07:17:57 +0000

The Real Problem: The Grind and The Dream

Like many of you, I'm tired. Tired of the corporate grind, tired of being the solo-dev bottleneck, and most of all, tired of watching my own projects languish because there's "always something to do" for the company. The dream is to break free - to work on my own things, on my own schedule, at my own pace.

That's the motivation behind DinkySub (Hopefully, my ticket out!).

I had an idea for a tool and a goal: ship a beta, fast. This time, I decided to tackle the project not alone, but with my new AI partner, Kiro. I had worked with Kiro on my previous project, WorryBox, where I experimented with letting Kiro do all the code. For WorryBox I was just the project manager. But this time I'd be in the driver's seat, using the AI as an accelerant, not a replacement.

🛠️ The Good Stuff: My AI Accelerant

Using Kiro as a highly skilled assistant, I was able to slash my project timeline dramatically. What I'd traditionally budget as a 6-month side project was beta-ready in just 2 months. Here’s where Kiro was truly invaluable:

⚡ Rapid Scaffolding: Kiro whipped up the initial app skeleton—database connection, user login, and routing—in minutes. I've wasted hours on this using my own boilerplate or heavy frameworks like Sails.js. This alone was a huge time saver.

⚖️ The Architectural Rubber Duck: When I was genuinely stuck between two or three different implementations, Kiro could articulate the pros and cons of each. It was like having a smart, impartial senior dev to talk through the trade-offs.

🔄 Unstoppable Momentum: The best part? Kiro kept the pace high. Because I retained control of the core logic, I felt confident and in sync. The speed allowed me to stay motivated and avoid the burnout that kills most side projects.

💥 The Problems: My AI's Very... Creative Mistakes

This isn't a flawless success story. Kiro's biggest flaw is that it is definitely not business-minded. Our partnership was a rollercoaster, and I had to spend a lot of time double-checking its "confidence."

💰 'Free Subscriptions For Everyone!'

I had a painful experience settling on a payment processor. After Stripe failed to verify me (for reasons unknown) and PayPal instantly closed my account after reviewing WorryBox (no details there either), I landed on Paddle. Honestly, the setup was a pleasure... until Kiro got involved.

I asked Kiro for help with the Paddle implementation. It confidently set things up, added the required keys, and declared it "production-ready!"

It was not.

Kiro had used the completely wrong API implementation. And, hilariously, it added a feature I'm calling the "Auto Accept Fallback."

🚨 Kiro's "Business Logic": If the payment method fails, just automatically accept the subscription anyway, requiring no payment.

Yes, my AI co-pilot tried to turn DinkySub into a pro-bono passion project!

I found the correct Paddle documentation and was pleasantly surprised to find Kiro could read the URL I provided and restructure the code. However, it stubbornly reintroduced the "Auto Accept" fallback, and then, after I asked it to remove the fallback, it put back the original, non-working implementation of paddle!

After several hours of manual surgery, I stripped out Kiro's code and installed the correct payment implementation myself. Payments finally worked. (Until I asked Kiro for help on the analytics page, and it managed to re-break the payment code again by trying to sneak in its favourite, incorrect method!)

🐛 The TypeScript Tantrum

The second major frustration was Kiro's penchant for creating build-breaking TypeScript errors. Time and time again, I'd ask for a feature, and the resulting code would fail to compile due to a TS issue.

The frustration was real, but the defence is simple: Kiro was also the solution. I just had to say: "You caused build errors. Please fix them."

And Kiro would dutifully burn through my credits, building, testing, and fixing its own mess until the code was clean again. A very expensive, but reliable, QA process!

✅ Overall: AI as an Employee, Not a CEO
Working with Kiro as a coding partner is certainly an adventure. It is lightning-fast and great for scaffolding and architecture, but requires a human with a healthy dose of suspicion and an eye for business logic.

The net result is undeniable: A 6-month project was finished in 2 months. And by using Kiro as an assistant instead of asking it to "do it all" (my mistake with WorryBox), I mostly managed to keep a handle on my credit usage.

If DinkySub takes off, I will definitely subscribe to the paid tier of Kiro. I might even list it as an employee on the company roster.

🙏 Your Turn: Check out DinkySub!

If you're interested in this journey, please feel free to give DinkySub a try at DinkySub.com

And if you find it useful, a subscription would help a fellow developer get one of those lives you keep hearing about on YouTube and Instagram. You can also support the project and get access via my Patreon page. (Supporters get a DinkySub subscription plus some other benefits.)

With 2 subscribers, DinkySub is self-sustaining.
With 300, I have a good side hustle.
With 1000+, I could potentially give up going to an office. :p

I welcome any comments, suggestions, or feedback! (Though if you have a bug report, please send it - I will deal with it, but I refuse to welcome it 😉).

**What are your thoughts on using AI for side-project development? Have you had any similar experiences with an AI co-pilot making hilariously bad business decisions? Which AI coding tool do you find works best for you?"

WorryBox

Andrew Hewitt — Fri, 12 Sep 2025 00:40:29 +0000

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