You have probably heard about David Allen’s famous 2-minute rule: if you can do something in less than two minutes, just do it.Otherwise, postponing it, adding it to your to-do list, and coming back to it later will take more than the 2 minutes you would have “invested” in dealing with it in the first place.
I believe we now need a similar rule for vibe coding:
If you can build the app you need in two hours or less, just do it.
I recently vibe-coded in two hours a small app to manage shared expenses for trips with friends. And another one to randomly display pictures from my Google Drive folders (yes, a strange place to store family photos). Obviously, there are (most likely) plenty of apps for both. But finding them, comparing them, testing them, creating an account, discovering that the free version is too limited, realizing that the app does not work exactly as you want, getting annoyed, and trying another one can easily take more than two hours… So, why not use those two hours to create exactly the small app you need?
I know, I know, this goes against the traditional recommendation to avoid the Not Invented Here syndrome. Until now, developing your own version of an existing application was, in most cases, a bad use of your time. But vibe coding (or “agentic development” if we want to look cooler) changes the economics of this decision. For a growing category of small apps, creating the tool you need may now be faster than searching for an existing one and adapting your way of working to it.
I’m basically talking about simple apps that are useful to you, even if nobody else ever uses them. In fact, even better if you don’t make them widely public (this would require more features like multi-user management, security analysis…. that would spill over the 2h). They can be throwaway apps. They do not need a roadmap, a community, or a sophisticated architecture. You use them for as long as they are useful and discard them afterwards.
But make sure it is really a two-hour app
Let me emphasize this again: There is a risk with my rule: what looks like a two-hour app may end up taking two days, two weeks, or much more.
This happens especially when people try to clone an existing application. As I discussed in Why cloning an app with vibe coding fails, when cloning an app, we tend to reproduce only what we can see. And what we see is much less than what the application actually does. We do not see all its validation rules, security checks, error-handling mechanisms, accessibility features, recovery procedures, or corner cases. In fact, we see only the part of its behavior that corresponds to the way we personally use it. After two hours, we may have something that looks like the original application. This does not mean that we have cloned it.
Therefore, the goal of the 2-hour rule should not be to reproduce an existing product. It should be to build the smallest application that solves your specific problem. And the two hours should be a real timebox:
If you do not have a useful version after two hours, stop and reconsider whether building it yourself is still the best option.
Avoid the sunk cost fallacy. The fact that you already spent 2h (and a few tokens) should not be a reason to spend even more. This also applies to the app maintenance. A two-hour prototype that generates dozens of hours of maintenance is not a two-hour app.
Keep in mind that the 2-hour rule is not an invitation to rebuild every piece of software we use. It is an invitation to recognize that, sometimes, creating a tiny tool adapted to your needs is now cheaper than finding the “optimal” existing one.