51–60 of 390 posts
I get that this is tempting but it just means you'll slowly get dependent on things that will eventually break in ways you will have no capacity to fix. And disaster recovery is most certainly a manual task.
In what situation would a simple script or helper app just suddenly rot away and stop working?
Of course it's POSSIBLE to vibe together a massive monstrosity of an everything-app, but that's not what the author is doing here (nor me).
Once you identify something like Handy, instruct Claude to study how that OSS project actually builds the feature and adapt the logic to your stack. AI is really good at finding the "seams" (those connection points where a feature ties into the tech stack) and understanding the full implementation.
The trick is knowing precisely where the feature lives in the code (files, functions, modules), because AIs often miss scattered pieces and don't capture everything otherwise. That's what I'm working on at opensource.builders[1]: turning OSS repos into a modular cookbook of features you can remix across stacks, with structured "skills" that point to the exact details so the porting works reliably.
Yeah. Part of why this is possible is simply that there are tons of subscription apps out there that were never really justified in requiring a recurring payment and are actually fairly trivial. It used to be that you offer subscriptions only if there are ongoing costs, and a one-time payment if not (utilities, local, etc). SaaS kinda ruined that. I'd welcome a boom in DIY vibe-coded utilities for personal use.
What I fear is a pollution of the open source space with tons of tailored apps that have a lot of overlap, but none of them get meaningful contributions because the maintainer will most likely respond with wontfix to almost everything (if they respond at all).
But I'm not going to start adding features to my bespoke utility to fix someone else's problem.
I did this recently at the company I work at. Someone suggested GitBook, I 'Vibe coded' an internal docs website in under and hour. Does what we need, looks good. Unless the app has a large community/network and is just a SaaS with some offering, it'll be very easy to replace it.
It's interesting, because a few years ago I would have put this strictly under the "not invented here" fallacy, where we'd now be stuck maintaining another project for the foreseeable future. I used to press pretty hard to avoid it. Now I wonder if the maintenance cost for this type of internal system has gone down to a level where that is no longer an issue.
Earlier quoted context omitted.
> you'll slowly get dependent on things that will eventually break in ways you will have no capacity to fix If the commercial provider charging you $10 a month breaks it, you also have no capacity to fix it. Your options are: send them an email, or unsubscribe and use something else.
Right but most of the time, in my experience they keep the lights on.
But if they remove a feature I rely on, I can't put it back.
If they add a feature I hate, I can't remove it.
If they jack the price up, I have no real solution to this.
If they move features I rely on from the standard tier to the 5x more expensive pro tier, I have no real solution to this.
Why, yes, this is an echo of the old argument for open source software.
This is a fun article and approach. Subscription apps often have to target a wide userbase. However, most users only need a small subset of the entire feature set, and would be better served by a tailored version. This means that vibecoded apps can get away with being much less complex (specific featureset, no login etc), while still being more useful. I have also created tools with LLMs that are exactly tailored to…
Once again, it took me about an hour while watching my shows to get a custom one made.
The first version operated by me downloading the pages one by one to a directory, the Python app parsed the html, downloaded the files and renamed according to thread name.
After a few iterations the tool just grabs a cookies.txt file exported from Firefox and can take any thread URL, browse through it, skipping existing files and determining if everything is already downloaded
I could easily have it just watch a set of threads for new content and download automatically, but the current system is fine =)
Turning a paid sub like WisprFlow into your own weekend build (Jabber) is a great move, but you can take it further by finding open-source alternatives that already implement the features you're replicating. For dictation and speech-to-text like what WisprFlow does, there's Handy[0], a free, open-source, offline speech-to-text app that runs locally with Whisper models. Once you identify something like Handy, instruct…
This is the same for me and I've not written code for years since I was a kid in school. I vibe coded a webapp that I was paying yearly for and the version I made does everything I wish the app I paid for did as it's 100% personalised to me. I've been thinking for awhile that this is going to be the future and I'm already starting to think of more things I will create.
I made the same realization two weeks ago. Posted about it here, where I rebuilt bare bones todoist with a habit tracker, goal setting and more within a few vibe coding sessions: https://news.ycombinator.com/item?id=46633092 I think that many existing apps with huge userbases will gradually lose users as the models become better and better. Their biggest advantage is that people don't like change, and thus having to…
> But as the models get better and the quality of the output will match the quality of the established SaaS but tailor the whole thing to a single user with the ability to make any change they can imagine within minutes, and perhaps deploy to Hetzner and whatnot where they could host all of those apps for a single $5 instead, the exodus will accelerate. I do think you're vastly overestimating people's ability to writ…
People in general would recoil in horror if they knew how many essential operations are backed by a mess of Excel sheets with formulas and VBA nobody understands anymore.
All it needs is the maker mindset of being just lazy enough to be bothered by a repetitive task and the courage (and permission) to use an Agentic LLM to figure out a fix for the issue.