Building and launching a product in one month. Worth it?
- Sergio Visinoni from Sudo Make Me a CTO <makemeacto@substack.com>
- Hidden Recipient <hidden@emailshot.io>
Building and launching a product in one month. Worth it?How a minor itch led me down the rabbit hole of building and launching a product in an unsexy space. How I turned that into an experiment and my first observations on the results.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 originsI 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:
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:
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 resultsAs 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 GoodFirst 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 BadWhile 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.
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 UglyWhile 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:
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. 1 NIH stands for Not Invented Here. 2 As much as I love to do so, my ISP is not reliable enough to be considered a viable option for high-uptime services. Then, you could argue that a few broken links every now and then wouldn’t be the end of the world, but that’s just you trying to be too rational. 3 In case you’re wondering, those websites are https://sergiovisinoni.com/ and https://doineedaifor.it/. They’re not exactly pushing the boundaries of what’s possible with web technologies, so you might understand my itch to find something a bit more sophisticated to work on. 4 Booklore, a sleek solution for self-hosting ebook collections 5 It seems like brain implants will make the typing part optional, broadening the spectrum of future software engineers to include all species, including fishes and birds who would have a very hard time with Vim’s commands otherwise. 6 I know, it sounds weird to do in real life something that we’ve always thought was relegated to pretentious system design interviews. Take it as a sign of being able to leave your comfort zone, and don’t forget to bring it up in your next behavioural interview. 7 In hindsight, this turned out to be a bit naive on my end. GitHub is full of crappy projects nobody ever finds out about, and while the repo has been public for a few weeks now, I don’t believe any human being has noticed its existence yet. I guess these days the best way to hide something is to publish it on a public repo. 8 As these things go, he got an error 500 upon signing up. It’s good to have friends who report issues but don’t judge you for making a fool of yourself. 9 Mind you, I didn’t say movie expert. So, even though the term might come across as pretentious, it refers to my interests, not any self-proclaimed ability or competence. 10 Watch it, it's worth it. 11 I genuinely believed that unregistered meaningful 4-letter domains were as extinct as velociraptors, and I was almost embarrassed to be able to register the two of them for $48 in total. There are still corners of the internet that have not been completely swallowed by grifters. There’s hope. 12 In case you missed the subtext, now is the time to go in there and star/watch/share the repo. 13 As much as I dislike most of the terminology around these tools, I tend to prefer the word 'agent' over 'AI’ for a simple reason: while an agent acts, the term doesn’t have any implicit assumption of whether the actions are good, bad, intelligent or just silly. They just act like any other form of automation ever invented until now. 14 This is a metaphor for AI-assisted tools. I didn’t suddenly go nuts on Adderall or ketamine. 15 You might be familiar with the famous post “I want AI to do my laundry and dishes so that I can do art and writing”. 16 OK, maybe not the Segway You're currently a free subscriber to Sudo Make Me a CTO. For the full experience, upgrade your subscription. |
Similar newsletters
There are other similar shared emails that you might be interested in:

