Nedávno jsem si udělal jednoduchou aplikaci, která řeší můj konkrétní problém, mou potřebu. Pod příspěvkem, kde jsem se o ní zmínil, se rychle objevila reakce, že podobnou funkci už přece dávno nabízí plno jiných, zavedených aplikací. Tak proč jsem to vůbec dělal, proč jsem si neudělal průzkum trhu a nepoužil už něco dávno hotového, prověřeného, fungujícího, levnějšího a plno dalších argumentů.
Jak se zdá, je to totiž jeden z nejběžnějších argumentů proti osobním nástrojům vzniklým díky explozi vibecodování vůbec. A současně brzda, proč se o nich tolik veřejně nemluví. Pod každým druhým příspěvkem, kde se s podobnými nástroji autor pochlubí, se slétne v podstatě vždy obdobná letka dravců, klovajících do masa. A autor snažící se podělit o svou radost z vařešeného problému dostane jednoduše řečeno sodu.
Argument odpůrců zní jednoduše: proč stavět vlastní nástroj, když už existuje hotové řešení. Zní to rozumně a ještě nedávno to rozumné opravdu bylo. Jenomže přišly jazykové modely a jejich schopnost připravit i laikovi takový nástroj snížila bariéru tak nízko, že ji dnes přeleze i třínohý jezevčík.
Než půjdu dál, stojí za to říct, co osobní aplikací myslím: software vytvořený primárně pro vlastní potřebu, bez ambice stát se masovým produktem pro stovky nebo tisíce uživatelů. Může to být aplikace, webová stránka, krátký skript, skill pro Claude Code nebo klidně veřejný projekt na GitHubu. Bez ohledu na formu, záměr tvůrce zůstává stejný. Tomuhle přístupu by se dalo říkat digital craftsmanship – řemeslné utváření vlastního digitálního prostředí.
Tři otázky
Za argumentem „na to už existuje appka“ se schovávají tři různé otázky.
První otázka zní, jestli existuje aplikace, která umí podobnou funkci. Odpověď je skoro vždycky ANO. Pro naprostou většinu běžných problémů dnes něco hotového existuje.
Druhá otázka je, zda ta existující aplikace dost přesně sedí na to, co potřebuju. Jinými slovy řeší přesně můj postup, moje vstupy, moje výjimky anebo mě nutí přizpůsobit se jejímu obecnému řešení. Tady už odpověď nebude jednoznačná. Existence podobné funkce ještě neznamená 100% shodu. Troufám si říct, že každý uživatel jakékoli aplikace někdy narazil na něco, co mu prostě v software chybělo, nebo se musí aplikaci nějak přizpůsobit, přestože by to jinak nedělal.
A nakonec třetí otázka, a nejdůležitější, zní, zda i s touhle nedokonalou shodou je levnější přizpůsobit se hotovému nástroji, nebo si postavit vlastní.
Právě tahle poslední otázka se v posledních letech zásadně proměnila. Dřív byla rada „nevymýšlej kolo, na to už existuje appka“ ekonomicky velmi rozumná. Protože pokud by vlastní řešení znamenalo sto hodin programování, bylo by absurdní ho stavět kvůli jediné funkci, kterou navíc ještě někdo nabízí za pár stovek ročně. Ale pokud dnes vytvořím osobní nástroj pomocí AI za dvě hodiny a pak ho používám přesně tak, jak potřebuju, argument „ale existuje na to produkt“ přestává být argumentem, je už jen lpěním na status quo.
Cena alternativy se změnila.
Ekonomika
Tohle je jádro celé věci. Bariéra pro napsání i jednoduchého nástroje jako znalost programovacího jazyka, frameworku, ladění detailů, které s vlastním problémem nesouvisely, byla dřív vyšší než hodnota, kterou nástroj mohl přinést. Dnes se dá funkční prototyp postavit řádově rychleji, protože velkou část téhle práce dokáže odvést Claude Code, Codex, Cursor nebo třeba Lovable či české Macaly. Neznamená to samozřejmě, že produkt pro tisíce uživatelů teď stojí výrazně míň práce, stále vyžaduje solidní inženýrství, architekturu, zabezpečení, údržbu. Mění se ale ekonomika malých, jednoúčelových nástrojů. Vzniká tak zcela nová kategorie.
Otázka, jestli se vlastní nástroj vyplatí, se dá zjednodušit na jednoduchou rovnici: čas na vytvoření plus čas na údržbu musí být menší než čas nebo peníze, které nástroj ušetří, plus hodnota zkušenosti, kterou jeho stavěním člověk získá. A je jedno, jestli nástroj používá jeden člověk, nebo milion.
Cena alternativy, jak jsem o ní mluvil, se sice změnila, ale námitka „to už tady je“ není tak úplně nová. Stejný argument se objevoval v éře low-code nástrojů, ještě před nástupem dnešní generativní AI. Proč používat Make (Integromat), Zapier, když tu máme API propojení a programátora, který to propojí nebo profesionální integrátory? protože to je levnější a často i rychlejší. (Mimochodem, i na tomto poli AI dramaticky snižuje náklady, takže šlape svým způsobem na paty nejenom klasickému vývoji, ale právě i tomuto low/no-code trendu.)
Ronald Coase ve své teorii firmy z roku 1937, rozvedené později Oliverem Williamsonem do transakční ekonomie, ukázal, že hranice mezi tím, co si necháme vyrobit sami, a tím, co si koupíme na trhu, není daná ničím jiným než poměrem transakčních a výrobních nákladů. Danou věc vyrobíme sami ve chvíli, kdy je to levnější, než když bychom ji měli koupit venku i s náklady na hledání, vyjednávání a přizpůsobení.
Přesně tahle úvaha teď sestupuje z firem na jednotlivce, jen s tím rozdílem, že se v ní obrací poměr, který dřív u softwaru téměř vždycky vycházel ve prospěch nákupu. Je to stejná logika, jakou běžně používáme třeba u vaření. Nemá smysl si sám připravovat složitý pokrm, který by zabral celý večer a nakonec by nebyl tak dobrý, když si ho můžu za deset minut objednat v restauraci vedle. A naopak, kdy má smysl si jiný pokrm udělat doma, protože náklad na jeho tvorbu a suroviny je neporovnatelný s náklady, jež by nám narostl objednávkou v restauraci. Nebo doručením kurýrem domů.
Bezpečnost
Druhá častá námitka – a oprávněná – je bezpečnost takových nástrojů. „Je to jen pro mě“ logicky snižuje nároky na univerzálnost, kompatibilitu nebo škálování, a často i nároky na bezpečnost. Osobní kalkulačka, skript, který pracuje výhradně s vloženými daty a vizualizuje je do dashboardu, a osobní asistent s přístupem ke Gmailu, API klíčům a účetnictví jsou z hlediska rizika úplně jiná liga – bez ohledu na to, jestli běží uvnitř vašeho počítače, v kontejneru, nebo veřejně na serveru.
Asi každého napadne, u kterého z nich může být amatérsky napsaný nástroj s přístupem k citlivým datům reálně nebezpečnější než cokoliv, co byste si koupili hotové. Chybí mu totiž právě to, co by mělo být u produktu samozřejmostí.
Pozor, to ale není argument proti osobním nástrojům! Je to pouze připomínka, že úspora práce na jedné straně nesmí znamenat rezignaci na bezpečnost na straně druhé, a že je potřeba vyhodnotit míru rizika daného nástroje, dat, přístupů a oprávnění, a podle toho s ním zacházet.
Svoboda
Kromě nižší ceny má stavění vlastních nástrojů ještě dva rozměry, které se snadno přehlédnou, protože nejsou tak snadno měřitelné jako čas nebo peníze.
Ten první je kontrola nad vlastním digitálním prostředím. Kdo používá hotové SaaS aplikace, se dřív nebo později přizpůsobuje rozhodnutím jejich autorů: rozvržení obrazovky, workflow, které považovali za správné, funkcím schovaným za vyšším tarifem, nebo naopak těm, které nejde vypnout. Tahle adaptace je tak samozřejmá, že si ji většina lidí ani neuvědomuje jako cenu, kterou platí. Když si člověk postaví vlastní nástroj, ten poměr se obrátí a prostředí se najednou přizpůsobuje jemu, ne on programu nebo úmyslu jeho tvůrců. A to včetně podpory špatných návyků, nesprávných workflow a rozhodnutí autora.
Druhý rozměr je nezávislost na rozhodnutích, která nemám pod kontrolou. Hotová služba může zdražit, zrušit funkci, na které jsem závislý, změnit API, na kterém stojí moje integrace, nebo prostě zaniknout i s firmou, co za ní stála. Nebo ji koupí Google a ten ji vypne. Vlastní nástroj tohle riziko nemá a nikdo mi ho nezdraží ani nezruší. Má samozřejmě jiná rizika, hlavně že si ho musím sám udržovat, ale je to riziko, které mám ve svých rukou, ne v rukou někoho jiného.
Kritici
Kritika osobních nástrojů má tendenci sklouzávat od jedné otázky ke druhé, aniž by spolu často souvisely. Začíná otázkou potřebnosti (k čemu vlastně ten nástroj je, když existuje něco hotového), aby se snadno přešlo k otázce technické kvality, přes jak je to napsané, jestli je to elegantní, jestli by to obstálo jako profesionální kód (ty to „vajbkóduješ“, nevíš, jak na to, AI dělá nekvalitní kód, není to bezpečné). A odtud už je jen krůček k otázce kompetence a kredibility autora (co to vypovídá o tom, kdo to udělal, když někde jinde a jindy udělal tamto).
Dlužno podotknout, že tyto otázky (zejména první dvě) obvykle kladou ti, kdo jsou pokrokem v oblast jazykových modelů nejvíce ohroženi. Nebo si to alespoň myslí. Otázky na kvalitu kódu slyšíme nejčastěji od programátorů, kteří vidí, jak model za pár minut zvládne totéž, co se oni sami roky učili, a pokud jejich profesní hodnota dosud stála jen na tom, že tohle umí jen málokdo, cítí se logicky ohroženi. Otázky designu a přívětivosti zase zaznívají od lidí okolo produktu a UX, kteří sledují, jak neučesaný, ale funkční nástroj bez jejich pečlivě navrženého procesu přesto řeší problém, a zpochybňuje tím hodnotu právě téhle části jejich řemesla. Oba se mýlí, jejich hodnota snižována v tomto případě není, protože by jejich kvalifikaci a znalosti autor podobného osobního nástroje pravděpodobně nevyužil. Aplikace by totiž ještě před dvěma třemi lety jednoduše nevznikla.
Třetí otázka, kompetence autora, s aplikací samotnou většinou má prachmálo společného. Je to spíš otázka vypovídající o nás – jsme lidé, a tak snadno překlopíme nesouhlas či nelibost s věcí v nesouhlas s člověkem, který za ní stojí. Tato chybná atribuce, nebo také horn efekt, vede k tomu, že jedna negativní vlastnost (v tomto případě aplikace) zbarví celý úsudek o člověku, který za ní stojí.
Odpovím tedy jen na první dvě námitky. Osobní nástroj může být zbytečný pro 99,9 % lidí, technicky neelegantní, nehezký a naprosto neprodejný jako produkt, a přesto být pro svého jediného uživatele naprosto racionálním a skvělým řešením. Žádná z těch věcí neplyne z té druhé. Aplikace nemusí být dobře napsaná podle standardů produkčního softwaru, aby dobře plnila svůj účel.
A naopak to, že aplikace nikoho jiného nezajímá, nic neříká o tom, zda a jak je dobře napsaná. A jestliže je napsaná neelegantně, pak to nic neříká o kompetenci člověka, který ji napsal pro sebe, na koleni, za odpoledne, protože u takového nástroje elegance kódu nikdy nebyla cílem.
Publikace
A co když se rozhodnu nástroj publikovat? Hranice mezi osobním nástrojem a produktem není binární přepínač, ale spektrum. Necháte-li si aplikaci jen pro sebe, žádná produktová odpovědnost vám tím logicky nevzniká. Zveřejníte-li ji na GitHubu nebo dáte zdarma na web, samo o sobě to ještě neznamená, že se stala produktem, ale roste tím počet lidí, kteří na ni mohou spoléhat, a s tím i odpovědnost, byť třeba jen morální.
Nebezpečnější je mezikrok, kdy nástroj nezůstane jen u autora, ale začne ho používat manželka, kamarád nebo kolega. Není to ještě zveřejnění, žádný GitHub ani web pro kohokoliv. A přesto tenhle jediný další uživatel okamžitě vytváří očekávání podpory a oprav, aniž by za tím stál jakýkoliv byznys, který by ten závazek unesl. Autor se ocitá v roli neplaceného podporovatele nástroje, který nikdy jako podporovaný vzniknout neměl. A najednou nástroj navržený na míru jednomu workflow nepočítající s potřebami ostatních uživatelů je dostupný a uživatelé, zejména, pokud zaplatí, očekávají logicky podporu. Přitom nástroj jako takový byl možná autorem tvořen formou „as it is, používej na vlastní riziko“.
Zveřejnění a sdílení navíc nemuselo mít vůbec za cíl, aby aplikaci ostatní převzali jako hotové řešení nebo komerční produkt. Může jít jen o důkaz, že to jde, a pozvánku, ať si každý postaví vlastní verzi přesně na míru sobě, ne aby používal tu moji. Nebo používat, ale za předpokladu neočekávání přizpůsobení, protože aplikace nevznikla jako cesta ke zbohatnutí, ale jednoduše jako náplast na jeden konkrétní problém. A pokud máš ten problém i ty, tady je to, co funguje mě a klidně si to použij také.
To je postoj, který nemusí každému sedět a přesto má na trhu aplikací své místo.
Dobrou ukázkou jsou dotfiles, které lidé běžně sdílí na GitHubu, klidně i s tisíci hvězdiček – jsou veřejné, zdarma, a přesto je nikdo nepovažuje za produkt, protože každý ví, že bere řešení šité na míru někomu jinému. Nebo nyní moderní skills pro nástroje typu Claude Code/Cowork či ChatGPT Work.
Harvardský profesor Yochai Benkler to popsal jako commons-based peer production, produkci mimo tržní logiku, od open source softwaru po Wikipedii. Zveřejnění zdarma proto samo o sobě neznamená vstup do světa produktů; je to jiný, dávno popsaný způsob produkce, ne jeho zmenšená verze. Jediná podmínka poctivosti je nástroj takhle i pojmenovat, tedy jako osobní řešení, ne jako produkt s podporou.
Co z toho plyne?
Dlouhá léta jsme museli přizpůsobovat svůj způsob práce softwaru, protože napsat vlastní nástroj bylo drahé a zdlouhavé. Generativní AI tenhle předpoklad změnila. Neznamená to, že si dnes má každý psát vlastní aplikace, znamená to umět se zeptat, jestli se mi to vyplatí víc, než sáhnout po něčem existujícím. A do úvahy patří nejen čas a peníze, ale i to, komu bude patřit moje pracovní prostředí, jak bude vypadat mé workflow a na kom budu záviset. A pokud si na tyto otázky umíte odpovědět, už asi znáte odpověď i na otázku z titulku tohoto článku.
