Vibecoding, nebo vývojář? Kdy si aplikaci napsat sami a kdy to nechat profesionálovi
Vibecoding stačí na ověření nápadu i na interní nástroje s malým rizikem. Kde končí, kdy se vyplatí zaplatit vývojáře a proč nejlepší cesta bývá kombinace obojího.

Krátká odpověď: pokud stavíte interní nástroj, kterým chcete ověřit nápad, a nic vážného se nestane, když se rozbije, napište si ho sami. Jakmile aplikace pracuje s citlivými daty, s penězi nebo na ní stojí část firmy, zaplaťte vývojáře. A mezi tím je třetí cesta, která v praxi funguje nejlíp: prototyp si vibecodujte a vývojáře přizvěte ve chvíli, kdy se z prototypu stává systém.
V téhle debatě jsem v trochu zvláštní pozici. Vydělávám na obou stranách, protože firmám audituju aplikace, které si vibecodovaly samy, a zároveň stavím aplikace na míru. Nemám tedy důvod vám jednu z cest rozmlouvat. Zkusím spíš popsat, kde která funguje a kde končí.
Kdy si aplikaci napsat sami
Vibecoding je nejrychlejší způsob, jak zjistit, jestli nápad dává smysl. Nástroje jako Claude Code, Cursor nebo Codex postaví funkční aplikaci za večer a pro jednodušší webové aplikace naklikané z chatu stačí Lovable nebo Bolt. Provoz na hostované platformě vyjde zdarma nebo na stovky korun měsíčně, takže experiment nebolí ani rozpočet.
Největší výhoda ale není rychlost. Je to fakt, že aplikaci staví člověk, který firmě rozumí. Majitel ví, jak vypadá jeho sklad, jak počítá provize a co jeho lidi denně zdržuje. Externí vývojář by tyhle znalosti z něj doloval týdny, on je má v hlavě a může zkoušet, upravovat a zahazovat bez čekání na dodavatele.
Dobří kandidáti na vibecoding jsou interní přehledy, evidence, kalkulačky a drobné nástroje pro pár kolegů. Společné mají to, že výpadek znamená nepříjemné dopoledne, ne škodu. I u takového nástroje se ovšem vyplatí projít checklist pěti oblastí, hlavně hesla mimo kód a zálohy dat.
Kdy zaplatit vývojáře
Hranice vede tam, kde by chyba v aplikaci způsobila skutečnou škodu. Citlivá data zákazníků, fakturace, platby, sklad, cokoli, bez čeho se firma druhý den nehne. V těchhle situacích přestává být otázkou, jestli aplikace funguje, a začíná být otázkou, co se stane, když přestane.
Z auditů vím, co se v aplikacích psaných svépomocí typicky pokazí: hesla a data zákazníků v repozitáři, chybějící kontrola oprávnění u části endpointů, provoz na kancelářském počítači bez záloh a tichá poškození dat, která se projeví až po měsících. Podrobně jsem to rozepsal v článku o tom, co nacházím při auditech. Podstatné je, že tyhle chyby autor nevidí, protože aplikace navenek funguje. Objeví se, až když je pozdě.
Druhý důvod pro vývojáře je rozsah. Aplikace, které stavím na míru, mívají věci jako frontu úloh, role uživatelů, napojení na další systémy a oddělené prostředí na zkoušení změn. To jsou části, které z chatu nevypadnou samy, protože o ně musí někdo vědět a říct si o ně. Kolik taková práce stojí a z čeho se cena skládá, jsem sepsal v článku o ceně interní aplikace na míru.
Není to buď, anebo
Nejčastější chyba, kterou v téhle úvaze vidím, je brát ji jako volbu jedné cesty navždy. V praxi funguje kombinace. Vibecodujte prototyp, dejte ho pár kolegům a pár týdnů sledujte, jestli ho opravdu používají. Spousta nápadů skončí právě tady a je skvělé, že vás to stálo pár večerů místo statisíců za dodavatele.
Když se nápad chytne, přichází moment na vývojáře. Poznáte ho podle konkrétních signálů: aplikaci používají lidé mimo vás, chystáte se do ní pustit ostrá data zákazníků, začíná se dotýkat peněz nebo by její výpadek firma citelně pocítila. To je chvíle, kdy se z prototypu stává systém a kdy se každá odložená oprava prodražuje.
Prototyp přitom není vyhozená práce. Je to nejlepší zadání, jaké může vývojář dostat, protože místo popisu na papíře vidí fungující aplikaci, na které si lidé už ověřili, co potřebují. Vývojář pak typicky ponechá, co funguje, a přepíše místa, kde jsou rizika.
Časté otázky
Je vibecodovaná aplikace bezpečná pro firemní použití?
Pro interní nástroj, který nepracuje s citlivými daty, ano, pokud si pohlídáte základ: hesla mimo kód, zálohy a kontrolu, kdo se k čemu dostane. Jakmile aplikace pracuje s daty zákazníků nebo s penězi, doporučuju nezávislou kontrolu, protože nejčastější chyby nejsou při běžném používání vidět.
Kolik ušetřím, když si aplikaci vibecoduju sám?
Provoz na hostované platformě vyjde zdarma až na stovky korun měsíčně, takže hlavní náklad je váš čas. Skutečné srovnání ale musí počítat i s cenou pozdějších oprav, protože chyby v oprávněních nebo v konzistenci dat se opravují dráž, než by stálo jim předejít. Cenu práce vývojáře rozepisuju v článku o ceně interní aplikace na míru.
Musí se vibecodovaný prototyp zahodit a napsat znovu?
Většinou ne. Vývojář obvykle ponechá části, které fungují, a přepíše místa s bezpečnostními riziky nebo s duplicitní logikou. A i kdyby se nakonec přepisoval celý, prototyp vám ušetřil nejdražší část vývoje, tedy zjišťování, co má aplikace vlastně dělat.
Jak poznám, že je čas přizvat vývojáře?
Ve chvíli, kdy by výpadek aplikace nebo únik dat z ní znamenal pro firmu skutečnou škodu. Prakticky to bývá tehdy, když aplikaci používají lidé mimo autora, pracuje s ostrými daty zákazníků, dotýká se peněz nebo na ní stojí denní provoz. Čím dřív vývojář přijde, tím levnější je úprava směru.
Nemusíte se rozhodovat naslepo
Pokud už vibecodovaný prototyp máte a řešíte, jestli na něm stavět dál svépomocí, nebo přizvat vývojáře, přesně pro tenhle moment dělám audit vibecodované aplikace. Do týdne od přístupu k repozitáři dostanete písemný report s riziky seřazenými podle závažnosti a 90 minut konzultace, kde probereme i to, která cesta dává ve vaší situaci smysl. Stojí 12 000 Kč bez DPH a protože vydělávám na obou stranách, nemám důvod vám výsledek přibarvovat.