Today’s article is the story of a giant rabbit hole, or how a rather simple need turned into a month-long quest, adventure, time drain, or massive waste.

The jury is still out to evaluate the results, but nevertheless I’m here to share the story with you, my beloved readers.

This is the story of Rushomon, something you didn’t know existed until about 5 seconds ago. Its existence is unlikely to change your life, but the story of its making might.

But let’s go back to about a month ago, on February 1st.

The origins

I remember an old commercial, though I do not remember the product it was advertising. It depicted a man who was looking to accomplish a trivial task, but ended up fixing his entire house, as they encountered more and more issues to solve on the path: fixing a drawer, oiling a squeaking door, etc.

Similarly, after procrastinating for months, at the end of January I finally decided to work on a task I had neglected for long: setting up a self-hosted URL shortener service. I’ve already shared in previous articles that I’m making inroads in the self-hosted space. What I haven’t shared with you is just how awful Substack traffic statistics are.

‘Bad’ is too kind. They’re worthless.

And the worst thing: they haven’t visibly improved in the last few years. I guess the staff is too busy adding unnecessary “social” features to care for the basics of a blogging platform, so I needed to do something about it.

The main reason: I do share links to my articles in a few places, and I’m always interested in knowing which channel performs better, i.e., which channel is bringing in the most traffic. That’s not the goal in itself, of course. The goal is to know where to invest my time and energy to promote the newsletter.

So, a simple task: just look at one of the handful of available options for open-source services, install it, and use it.

Not so fast.

While I was going through the tedious process of vetting existing solutions based on stack, requirements and functionalities, I got hit by the disease commonly found among software engineers: the NIH syndrome¹.

And like anyone else afflicted by it, I made up perfectly reasonable arguments to sustain the idea that it would have been obviously better if I built my own solution.

Those included the following:

• This service needs to have a very high uptime, so I can’t really self-host it in my home server².

• I don’t like any of the existing online services because they’re often bloated or just too expensive for my needs, but their free-tier offer is often too limited.

• My recent experience with hosting my websites on Cloudflare Pages has been quite positive, and I intended to explore in depth their workers offer³.

• I keep telling myself I want to learn Rust but often lack a good idea for a project to put it into practice.

• In the past couple of months, I've been contributing to an open-source project⁴, which has reignited my old passion for building stuff for the community.

• Last but not least: the dominant narrative in the industry seems to be that even one-eyed cats with average typing skills will soon be able to build the next unicorn thanks to LLM-assisted development tools⁵. If half of what we hear is true, I should be able to get something done in about two days of prompting.

These arguments kept popping up in my mind while I was going through web searches and GitHub repos to evaluate available options, to the point that I finally gave in to the worms in my head and made a firm decision: I was going to build my own URL-shortener service⁶.

Now, I didn’t want to build just a toy project destined to end up on the huge pile of abandonware in a matter of days. Early on, I settled on a few principles that I believe would guarantee the project's longevity:

• The backend service will be written in Rust for safety and speed. And, importantly, because I have long wanted to get my hands into Rust.

• The frontend will be slick, lightweight, and lean, based on SvelteKit. A framework I never touched prior to this experience, but built on some principles that I found interesting.

• The project should be very easy to deploy on Cloudflare’s infrastructure and allow the average self-hoster to run it within CF’s free tier’s limits. In other words, anyone should be able to easily deploy it and run it basically for free, minus the costs of registering a domain if they didn’t have one already.

• I will offer both the self-hosted option and a managed service, with affordable prices and a generous free tier.

• I’ll build it by leveraging AI-assisted coding tools, as my long-term plan is to hand off maintenance to my two-eyed cat eventually.

• It’ll be 100% open source, under the AGPLv3 license. Both because I’ve long been a supporter (and contributor) to OSS software and also because of the implications of the previous point. Something you can read more about in another recent article.

The reverse Napster manoeuvre of Big AI Sergio Visinoni · Jan 21 Read full story

Deciding all that was the easy part.

As usual, the hardest challenge was coming up with a name for the thing.

That took a good couple of weeks longer. It wasn’t until February 9th that I registered the domains.

On February 1st, 2026, I made the first commit and pushed to a repo that was still private at the moment, as I wanted to see some traction in the process of building before going out in the public⁷.

A month later, let’s see where we are.

The results

As the saying goes, a picture is worth more than a thousand words.

Rushomon (more on the name later) is live, and sign-ups to the free tier are open to anyone with either a GitHub or a Google account.

Nobody has signed up yet except myself, my wife and a friend of mine I’ve shared the link with, as he’s also in the bootstrapped/indie dev space⁸. Not that I expected, nor wanted, anyone else to sign up, as Rushomon has not been advertised anywhere so far.

But the picture above shows that it’s been serving short URLs in production since February 25th. That’s when I created the first short link to be used for the original purpose of setting up a URL shortener: promoting my articles on different platforms and tracking their performance.

Specifically, I shared the URL for last week's article on a few Slack groups and a single subreddit as a test.

As you can see, the majority of the traffic is coming from Reddit, even the “direct” ones. Funnily enough, and to confirm my original suspicions, Substack’s official stats report a completely different number. Significantly lower. It only took me one month of long days and short nights (more on this later) to prove it, but it was worth it!

Now, back to Rushomon. What’s with the name?

Those who know me well know that I like to play with words.

Those who know me very well know that I am also a bit of a cinephile⁹.

Since the project's inception, I have been quite set on a name that would begin with the two letters ‘ru’, as that would go well for both RUst and Url.

It took me about 500 milliseconds to get there and two weeks to find the rest of the letters.

I was initially focusing on the URL world, so I looked at variations of rurl10 but found nothing interesting whose domain was available. At some point I thought of the rusho contraction, and that’s when the assonance with Akira Kurosawa’s masterpiece Rashomon¹⁰ struck me. I just had to make up a plausible explanation for the ‘mon’ part of the name, and the decision was set.

But besides registering the rushomon.cc domain to be the main domain for the web up, I was able to also secure a rare four-letter domain that doesn’t sound like Klingon: rush.mn¹¹.

In full honesty, I’m so hyped about the name and domains I was able to come up with for this project. It’s probably the best thing done for the whole project.

The full source code for Rushomon is available at this GitHub repo¹². It includes a script that should allow anyone to deploy it in a couple of minutes once they’ve set up the prerequisites, such as OAuth apps and domains. I’m very interested in hearing from other people testing the self-hosted approach and reporting issues or bugs.

At the time of this writing, version 0.4.0 is the latest and the one live in production. I’m currently working on finalising the integration with the payment provider so that paid tiers become accessible. The whole thing is still running on Cloudflare’s free tier, and I’m planning to upgrade to the paid workers plan as soon as the first paying client signs up.

But enough with self-promotion. I’m sure the reason you’re all still reading is because you want to learn more about the process of building Rushomon. Specifically, the section about AI-assisted development and the rise of single-eyed cats in the industry is particularly intriguing.

So, let’s do a bit of retrospective by using another movie analogy: The Good, The Bad and The Ugly.

The Good

First and foremost, in about a month I was able to build and ship a service in production. Rushomon wasn’t even a name a month ago, and now anyone can sign up and use it. And so far it has cost me $48 for registering the two domains and about $10 for an AI-assisted subscription tool. Plus, of course, an insane amount of time. I didn’t count it, as the idea of writing an article about the journey came up only halfway through, but I can tell you it’s been a nontrivial amount. Most of the non-allocated hours during the workday, and a lot of time during evenings and weekends, have been devoted to building Rushomon.

That said, being able to go from idea to product launch in a month is something I’m positively surprised about. Now, a non-trivial part of that agility is a testament to how far cloud services have gone in abstracting away a lot of the underlying complexity. The combination of GitHub Actions and Cloudflare Workers clearly made the development experience a breeze.

But only because I have experience in shipping stuff to production, and I had some clear principles in mind since I started writing the first lines.

Very early on I set up GitHub Actions to deploy any PR to dedicated ephemeral environments, to make testing in a production-like environment a breeze. And I set up CD to the production environment shortly after, as soon as the stack was in a deployable state (quite early, to be honest). That approach evolved only recently, roughly around the time I posted that first short link from the screenshot on various pages, as I wanted to add an extra layer of safety to the process by introducing a staging environment.

Despite tooling and platforms making the task relatively easy, I still invested a significant amount of time just in building and evolving the CI/CD pipeline. Such practices have always been a key component of the software engineering discipline. But for Rushomon they were even more important due to an additional factor: using AI-assisted tools for development.

Clearly, this was another factor that I believe helped me ship a product in such a relatively short time. But it’s actually the combination of AI tools AND good CI/CD practices that made it possible and sustainable. LLMs applied to software development can be helpful, as long as the right conditions are present. Based on my experience in the last month, I can’t imagine anyone without solid software engineering knowledge building anything more than scrappy prototypes with it.

As part of the experiment, I tested both CLI-based tools and IDE-based tools. While the former seems to capture all the hype, I found the experience with the latter, in-IDE assistance, better.

Not necessarily in terms of accuracy of results, which are notably difficult to assess, but in developer experience. CLIs tend to hide away a lot of the details from you, making it harder to inspect and review the work. They seem to promote a much more hands-off approach, which is the opposite of what I believe we need. With such tools, I see the need for human oversight only increasing, and likely exponentially, and I found the IDE experience more conducive to that.

You might have noticed that I haven’t mentioned any specific tool here, and that’s on purpose. Both because I tried many of them and, more importantly, because I don’t want any of this to come across as an endorsement or promotion. It’s just a summary of my own experience as someone who used to write a lot of code in the past and then became increasingly distant from it as I took on leadership roles. Not to be generalised.

But did I succeed in learning Rust along the way?

Not really.

The Bad

While I got more familiar with Rust code and its ecosystem, I can’t say I’ve learned as much as if I’d been writing all the code by myself. When the choice was presented to go slow and learn or go fast and move on to the next feature, I often found myself falling for the latter. So, though I did learn a bunch of things while building Rushomon, AI didn’t really enhance the learning experience but rather hindered it, as it shifted the incentives to quicker completion.

LLMs are inherently inaccurate and unpredictable. Meaning that when you use them, you both know that they will fail you and that you don’t know when they will do it. In what sounds eerily like an ancient Greek philosopher’s quote, the only thing you can trust LLMs with is that they are untrustworthy.

That’s already bad in itself, but it’s made exponentially worse by all the hype and propaganda that tries to minimise or hide away the problem from the masses.

Just to give you some examples from this last month. As I have been working on Rushomon with these tools, I have witnessed agents¹³ do the following.

• Delete failing tests as a way to make them pass.

• Write no-op tests that just logged success statements.

• Completely ignore rules written in multiple ways to harness their operation. I found it particularly annoying when, despite my multiple attempts at following the “standards” for rules to prevent it, they kept trying to commit code on my behalf.

• Present alternative options that were in fact the same, just worded slightly differently.

• Make up for APIs and docs that simply do not exist.

• Run queries to “fix” data in the DB to address an issue caused by a bug in the code, rather than fixing the bug itself.

And a few other things that I’ve already forgotten.

These shortcomings are all part of the untrustable nature of the tools. As such, they should not come as a surprise. I was able to catch most of those issues thanks to my attempts at diligently reviewing the code, aligning on decisions and plans, reading up on documentation, etc. But I’m pretty sure some slipped through, as it’s humanly difficult to keep up with all the side effects when operating at this pace.

Which leads me to the next point.

The Ugly

While I have enjoyed the act of building Rushomon, the overall experience of coding it has been a lot more miserable than I was used to when I was just writing code without any substance abuse to alter the performance¹⁴. There are three main reasons for that:

1. Cognitive load. The more you rely on such tools, the more your cognitive load increases. This might sound counterintuitive, as the promise is that you should instead be able to offload part of the cognitive load to these agents and automations. But due to their inherent untrustable nature and their annoying verbosity, they act erratically, like interns with personality disorders who can churn out a lot of code. That means you need to review everything, and reviewing someone else’s code makes it very hard to have the same level of focus and flow you get when you’re the one producing it. Imagine spending your day reviewing PRs. I guess that’s the modern equivalent of working at the patent office. No wonder why a lot of bogus patents are granted every year.

2. Context Switch. Closely related to the previous point is the fact that the current interaction with agents in the coding workflow is designed in a way that promotes context switches. While the industry has spent years making compilers and hot reload as performant as possible to help developers benefit from fast feedback loops while keeping their focus on the task, the “prompt and wait” interaction paradigm is the opposite. After a few seconds, your brain is immediately craving new stimuli. So you easily end up either firing up another agent and crafting another prompt (bad), or checking your emails and chat messages (bad), or wasting your time on news sites, doomscrolling social media, or anything equivalent (very bad). I find that combination of cognitive load and context switch exhausting. And they’re both compounded by the next point.

3. Dopamine Addiction. The most common interaction with such tools has something profoundly addictive to it. I’m not using the word loosely as a synonym of ‘exciting’ or ‘engaging’, but in its most literal form. I found myself doing weird things to keep the flow going. At some point I was doing the dishes while some code was being built and realised we probably got this whole thing backward¹⁵. I’ve been neglecting my sleep and exercise lately. In the last two weeks I have not been doing my usual weekly and daily planning, a discipline I’m very strict about except for when I’m on holiday. And I am coming from a position of enough self-awareness that allows me to observe myself and notice what is happening as it unfolds. I can’t imagine what this can do to people who are less equipped to handle such dangers.

Interestingly enough, as I was going through the process, I read a great article from Rachel Thomas from fast.ai that describes in very sharp terms the analogy between “Vibe Coding” and gambling. You can find it here, and everyone should read it.

What’s next?

In the immediate future I want to see how the OSS community reacts to Rushomon, and I’m prepared for it to land anywhere between going completely unnoticed to gaining support to being hated because it was built using AI. More importantly, I intend to dial back on the investment to regain control over my time and energy.

And definitely spend some time fixing all the bugs that have slipped through so far.

While most of you know that I’m mostly critical of the current tech industry and the GenAI hype, that doesn’t mean I should stop experimenting. But what this experiment made clear once more is that, when it comes to GenAI (or other technologies), we’re often asking ourselves the wrong question.

The question shouldn’t be “Is it helpful?”, as it’s generally easy to find some utility in any new technology or invention¹⁶. The question should be “Is it so helpful and beneficial as to justify its cost?”

By cost I mean the overall cost, not just the pennies we’re paying for it, as the whole thing is subsidised by VC capital.

Notice that I haven’t even mentioned all the “externalities” of GenAI in this article: its impact on the environment, human labour or theft of copyrighted material. In that regard, during the whole process of building Rushomon I often felt a sense of unease.

Like I was driving a massive internal combustion pickup truck in a protected national park while I would normally hike through it. Driving so fast, I’d often take the wrong road and have to drive back for kilometres, causing even more waste than if I’d gone slowly through each step.

In the meantime, I invite everyone to sign up for the free tier, try setting it up in their Cloudflare account, and share their thoughts on Rushomon.

In a time when everyone is chasing fancy and shiny objects, Rushomon would arguably stand out as unsexy in a rather boring space.

That’s a feature, not a bug. I believe that for solo entrepreneurs and indie hackers there are many opportunities to build better tools in boring spaces.

But that’s a topic for another article.