{"id":10350,"date":"2026-08-23T20:52:11","date_gmt":"2026-08-23T18:52:11","guid":{"rendered":"https:\/\/www.kubicek.ai\/?p=10350"},"modified":"2026-08-23T20:59:43","modified_gmt":"2026-08-23T18:59:43","slug":"is-it-worth-building-your-own-personal-apps","status":"publish","type":"post","link":"https:\/\/www.kubicek.ai\/en\/is-it-worth-building-your-own-personal-apps\/","title":{"rendered":"Is It Worth Building Your Own “Personal” Apps?"},"content":{"rendered":"\n

I recently built a simple app to solve one specific problem of mine, one specific need. Under the post where I mentioned it, a comment quickly showed up pointing out that plenty of established apps already offer the same feature. So why did I even bother? Why didn’t I do any market research and just use something that already existed, proven, working, cheaper \u2014 and a dozen other arguments along those lines.<\/p>\n\n\n\n

As it turns out, this is one of the most common arguments against personal tools born out of the vibe-coding boom. It’s also exactly why people don’t talk about them publicly all that often. Under almost every other post where someone shows off a tool like this, the same flock of vultures swoops in for the kill. And the author, who just wanted to share the satisfaction of having solved their own problem, ends up getting roasted for it instead.<\/p>\n\n\n\n

The critics’ argument is simple: why build your own tool when a ready-made solution already exists.<\/strong> It sounds reasonable, and until recently it genuinely was. But then language models came along, and their ability to help even a complete novice put together a tool like this dropped the barrier so low that these days just about anyone can clear it.<\/p>\n\n\n\n

Before I go any further, it’s worth clarifying what I mean by a personal app: software built primarily for your own needs, with no ambition to become a mass-market product used by hundreds or thousands of people.<\/strong> It could be an app, a website, a short script, a skill for Claude Code, or even a public project on GitHub. Whatever form it takes, the creator’s intent stays the same. You could call this approach digital craftsmanship \u2014 hand-building your own digital environment.<\/p>\n\n\n\n

Three questions<\/h2>\n\n\n\n

Behind the “there’s already an app for that” argument hide three separate questions.<\/p>\n\n\n\n

The first question is whether an app exists that does something similar.<\/strong> The answer is almost always YES. For the vast majority of everyday problems, something ready-made already exists. <\/p>\n\n\n\n

The second question is whether that existing app actually fits what I need closely enough<\/strong>. In other words, does it handle my exact workflow, my inputs, my edge cases \u2014 or does it force me to adapt to its generic solution instead? Here the answer stops being clear-cut. The existence of a similar feature doesn’t guarantee a 100% match. I’d wager every user of every app has, at some point, hit something the software simply didn’t cover, or had to bend their own habits to fit the tool, even when they’d rather not have.<\/p>\n\n\n\n

And finally, the third question, and the most important one, is whether even with that imperfect fit, it’s still cheaper to adapt to the existing tool, or to build your own.<\/strong><\/p>\n\n\n\n

It’s precisely this last question that has fundamentally shifted in the past few years. The old advice \u2014 “don’t reinvent the wheel, there’s already an app for that” \u2014 used to make excellent economic sense. If building your own solution meant a hundred hours of coding, it would have been absurd to build it just to replace one feature you could already get elsewhere for the price of a cheap annual subscription. But if I can now build a personal tool with AI in two hours and then use it exactly the way I need to, the argument “but a product already exists for that” stops being an argument at all \u2014 it’s just clinging to the status quo. <\/p>\n\n\n\n

The cost of the alternative has changed.<\/p>\n\n\n\n

The economics<\/h2>\n\n\n\n

This is the heart of the matter. The barrier to writing even a simple tool \u2014 knowing a programming language, a framework, wrestling with details that had nothing to do with your actual problem \u2014 used to be higher than the value the tool could deliver. Today a working prototype can be built an order of magnitude faster, because tools like Claude Code, Codex, Cursor, or Lovable, or Macaly<\/a>, can handle most of that work for you. That obviously doesn’t mean building a product for thousands of users now takes dramatically less effort \u2014 it still demands solid engineering, architecture, security, and maintenance. But the economics of small, single-purpose tools have changed. A whole new category has emerged.<\/p>\n\n\n\n

Whether building your own tool pays off can be boiled down to a simple equation: time spent building it plus time spent maintaining it must be less than the time or money the tool saves, plus the value of the experience gained by building it. <\/strong>And it doesn’t matter whether the tool ends up being used by one person or a million. <\/p>\n\n\n\n

The cost of the alternative may have changed, as I mentioned, but the “it already exists” objection isn’t actually new. The same argument came up in the era of low-code tools, well before today’s generative AI. Why use Make (formerly Integromat) or Zapier when you could just have a developer, or a professional integrator, wire up the APIs directly? Because it’s cheaper and often faster. (Incidentally, AI is dramatically cutting costs on this front too, so it’s nipping at the heels of both traditional development and the low-code\/no-code world.)<\/p>\n\n\n\n

In his 1937 theory of the firm, later expanded by Oliver Williamson into transaction cost economics, Ronald Coase showed that the line between what we make ourselves and what we buy on the market comes down to nothing more than the ratio of transaction costs to production costs. <\/strong>We make something ourselves the moment it’s cheaper than buying it externally, once you factor in the cost of searching, negotiating, and adapting. <\/p>\n\n\n\n

That exact same reasoning is now trickling down from companies to individuals, except the ratio, which for software almost always used to favour buying, is now flipping. It’s the same logic we apply to cooking. There’s no point spending your whole evening cooking an elaborate dish that won’t even turn out as good, when you could just order it from the restaurant next door in ten minutes. But on the other hand, sometimes it makes perfect sense to cook something at home, because the cost of the ingredients and your time is nowhere near what you’d pay ordering it at a restaurant. Or having it delivered.<\/p>\n\n\n\n

Security<\/h2>\n\n\n\n

The second common objection, and a fair one, is the security of tools like this. “It’s just for me” naturally lowers the bar for universality, compatibility and scalability, and often for security too. A personal calculator, a script that only visualises data you feed into it on a dashboard, and a personal assistant with access to your Gmail, API keys and accounts are in completely different risk leagues, regardless of whether they’re running on your own computer, inside a container, or out on a public server.<\/p>\n\n\n\n

It’s not hard to see which of these an amateurishly built tool with access to sensitive data could genuinely be more dangerous than anything you’d buy off the shelf. What it’s missing is exactly what should come standard with any real product.<\/p>\n\n\n\n

To be clear, that’s not an argument against<\/strong> personal tools! It’s simply a reminder that saving effort on one side must not mean giving up on security<\/strong> on the other, and that you need to assess the actual risk level of the tool, its data, its access and its permissions, and treat it accordingly.<\/p>\n\n\n\n

Freedom<\/h2>\n\n\n\n

Beyond the lower cost, building your own tools has two more dimensions that are easy to overlook, simply because they’re not as easy to measure as time or money. <\/p>\n\n\n\n

The first is control over your own digital environment. <\/strong>Anyone using off-the-shelf SaaS apps sooner or later ends up adapting to their creators’ decisions: the screen layout, the workflow they decided was right, features locked behind a higher tier, or, just as often, features you can’t turn off. This adaptation is so routine that most people don’t even register it as a cost they’re paying. When you build your own tool, that relationship flips, and the environment suddenly adapts to you, instead of you adapting to the software or its creators’ intentions. Bad habits, flawed workflows and questionable calls included, since now they’re your own.<\/p>\n\n\n\n

The second dimension is independence from decisions I have no control over.<\/strong> A ready-made service can raise its prices, kill off a feature I depend on, change the API my integration relies on, or simply disappear along with the company behind it. Or Google buys it and shuts it down<\/a>. A tool you build yourself doesn’t carry that risk, and nobody can raise its price or discontinue it out from under you. It comes with its own risks, of course, mainly that you have to maintain it yourself, but that’s a risk that sits in your own hands, not someone else’s.<\/p>\n\n\n\n

The critics<\/h2>\n\n\n\n

Criticism of personal tools tends to slide from one question to the next, even when the two aren’t really related. It starts with the question of necessity (what’s even the point of this tool if something ready-made already exists<\/em>), then easily slips into a question of technical quality, how it’s written, whether it’s elegant, whether it would hold up as professional-grade code (you just “vibe-coded” it, you don’t actually know what you’re doing, AI writes sloppy code, it’s not secure<\/em>). And from there it’s a short hop to a question about the author’s competence and credibility (what does it say about the person who built this<\/em>, given what else they’ve done elsewhere<\/em>).<\/p>\n\n\n\n

It’s worth noting that these questions (especially the first two) are usually raised by the people who feel most threatened by progress in language models. Or at least think they are. Questions about code quality come up most often from developers who watch a model pull off in minutes what took them years to learn, and if their professional worth has so far rested on the fact that few other people could do this, they understandably feel threatened. <\/strong>Questions about design and usability, meanwhile, tend to come from product and UX people who watch a scrappy but functional tool solve a problem without any of their carefully crafted process, which calls into question the value of that exact part of their craft. Both are wrong, <\/strong>their value isn’t actually being diminished here, because the creator of a personal tool like this probably wouldn’t have needed their expertise anyway. This kind of app simply wouldn’t have existed two or three years ago. <\/strong><\/p>\n\n\n\n

The third question, the author’s competence, usually has next to nothing to do with the app itself. It says a lot more about us \u2014 we’re only human, so we easily let disagreement or dislike of a thing slide into disagreement with the person behind it. This misattribution, also known as the horn effect<\/em>, means one negative trait (in this case, the app) colours our entire judgment of the person who made it.<\/p>\n\n\n\n

So I’ll only address the first two objections. A personal tool can be useless to 99.9% of people, technically inelegant, unattractive and utterly unsellable as a product, and still be a perfectly rational and excellent solution <\/strong>for its one and only user. None of these things follow from any of the others. An app doesn’t need to be written to production-software standards to do its job well.<\/p>\n\n\n\n

And conversely, the fact that nobody else cares about an app says nothing about whether or how well it’s written. And if it’s written inelegantly, that says nothing about the competence of the person who knocked it together for themselves, in an afternoon, on their knee, because for a tool like that, elegant code was never the goal.<\/p>\n\n\n\n


<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Publishing<\/h2>\n\n\n\n

So what happens if I decide to publish the tool? The line between a personal tool and a product isn’t a binary switch, it’s a spectrum. If you keep an app strictly to yourself, no product-level responsibility logically arises. If you publish it on GitHub or put it up free on the web, that alone doesn’t turn it into a product, but it does increase the number of people who might come to rely on it, and with that comes responsibility, even if only a moral one.<\/p>\n\n\n\n

The riskier step is the one in between, where the tool doesn’t stay with just its creator but a spouse, a friend or a colleague starts using it too. That’s not really publishing yet, no GitHub, no public website. And yet this single extra user immediately creates an expectation of support and fixes, without any business behind it able to carry that commitment.<\/strong> The creator suddenly finds themselves cast as the unpaid support desk for a tool that was never meant to be supported in the first place. And all at once, a tool built around one specific workflow, with no thought given to anyone else’s needs, becomes available, and users, especially if they’re paying for it, naturally expect support. Even though the tool itself may well have been built by its author on a strict “take it as it is, use at your own risk” <\/em>basis.<\/p>\n\n\n\n

What’s more, publishing and sharing something was never necessarily meant to have other people adopt the app as a finished solution or a commercial product. It might just be proof that it can be done, and an invitation for everyone to build their own version, tailored exactly to themselves, rather than using mine. Or use mine, but without expecting it to be adapted, because the app wasn’t built as a way to get rich, but simply as a band-aid for one specific problem. <\/strong>And if you happen to have that same problem too, here’s what worked for me, feel free to use it as well. <\/p>\n\n\n\n

That’s a stance that won’t sit well with everyone, and it still has its place in the app market. <\/p>\n\n\n\n

A good example is dotfiles<\/em>, which people routinely share on GitHub, sometimes with thousands of stars \u2014 they’re public, free, and yet nobody treats them as a product, because everyone understands they’re taking a solution tailor-made for someone else. Or, more recently, skills<\/em> for tools like Claude Code\/Cowork or ChatGPT Work.<\/p>\n\n\n\n

Harvard professor Yochai Benkler described this as commons-based peer production<\/em>, production that operates outside market logic, from open-source software to Wikipedia. Publishing something for free, on its own, therefore doesn’t mean entering the world of products; it’s a different, long-documented mode of production, not a stripped-down version of one. The only condition for honesty is to actually label the tool that way: as a personal solution, not as a supported product.<\/p>\n\n\n\n

So what does this mean?<\/h2>\n\n\n\n

For years, we had to adapt the way we worked to fit the software, because building your own tool was expensive and slow. Generative AI has changed that assumption. That doesn’t mean everyone should now go off and write their own apps, it means learning to ask yourself whether it’s actually worth it, compared to reaching for something that already exists. <\/strong>And the answer isn’t just about time and money; it’s also about who ends up owning your working environment, what your workflow will look like, and who you’ll end up depending on. And if you can answer those questions, you probably already know the answer to the question in this article’s title.<\/p>\n","protected":false},"excerpt":{"rendered":"

I recently built a simple app to solve one specific problem of mine, one specific need. Under the post where I mentioned it, a comment quickly showed up pointing out that plenty of established apps already offer the same feature. So why did I even bother? Why didn’t I do any market research and just […]<\/p>\n","protected":false},"author":1,"featured_media":10336,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[10],"tags":[],"cat_tool":[],"class_list":["post-10350","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts\/10350","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/comments?post=10350"}],"version-history":[{"count":4,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts\/10350\/revisions"}],"predecessor-version":[{"id":10361,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts\/10350\/revisions\/10361"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/media\/10336"}],"wp:attachment":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/media?parent=10350"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/categories?post=10350"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/tags?post=10350"},{"taxonomy":"cat_tool","embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/cat_tool?post=10350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}